Rob Howard presented the expanded support for caching in ASP.NET. Two main features were presented:
CacheDependency is now extensible. By overriding a small set of virtual methods, you can implement any cache dependency scheme. For example you can call a web service to check the validity of some data. You can use your custom CacheDependency instance to control output caching of a page:
Dim myDependency As New MyCacheDependency(...)
Response.AddCacheDependency(myDependency)
The other main feature is that Whidbey will support database cache dependencies. There is a separate implementation for Sql Server 7/2000 and for Yukon.
- Sql Server 7 & 2000 will support table-level dependency tracking. That is, for a given query, you declare the set of tables to watch. If data is changed in any of those tables, the cache entry will expire. Obviously, this is extremely pessimistic and thus is only suitable for tables that change infrequently. Also, a light-weight polling mechanism is used: when data changes, a trigger writes to a table with one row per table that is being watched. On a configurable interval, ASP.NET will poll the table and invalidate entries appropriately.
- Yukon will support row-level dependency tracking. It works in roughly the same way as indexed views. Think about it - when a table changes, the corresponding indexed views are updated. The same analysis that provides that functionality also provides the cache invalidation feature. The consequence is that the query in question is subject to the same constraints as indexed views. If a query is not supported, an invalidation notification is fired immediately. Exciting! Note that the client-side plumbing is handled by ADO.NET.
Database-driven cache invalidation is a real gift to the world!.
See my post, http://geekswithblogs.net/ewright/posts/309.aspx, for information on achieving table-level invalidation in ASP.NET 1.0!
I hammered the SQLXML guys at the PDC today. I want to know whether SQLXML is regarded (rightly) as awesome progressive technology, or merely a step towards either ObjectSpaces or (worse) XML datatypes in Yukon. Some points:
- SQLXML is not deprecated.
- It has been ported to fully managed code for Whidbey timeframe.
- In terms of the internal implementation, it will not depend on FOR XML syntax in the future, but rather on multiple active resultsets and client-side post-processing. Seems ass-backwards to me - they need deeper integration with the relational engine to avoid any denormalization whatsoever.
- In future releases you will not annotate your schema with SQLXML attributes. Instead, you will write a separate mapping file. BOO. Well, OK, it's no big deal. If you want to keep your annotations within the schema, use an XSL transformation to generate the mapping file. I think of annotations like custom attributes in managed code. It's a great innovation that they are inline, rather than in a separate file.
- ObjectSpaces and SQLXML use the same engine. I might be misunderstanding - the statement was interleaved with another conversation.
No matter what the implementation details are, the great thing about SQLXML is that from the client point of view, you get a normalized, heirarchical snapshot of your data in one round-trip to the server. It eliminates ugly SQL code in your app - you know, the stuff that either executes a query to fetch the details for each master record (aaah!) or re-normalizes with conditional logic. Plus, as the SQLXML implementation improves, you get wholesale speed improvements with no code or database changes!
I think SQLXML is a first step in a revolution in database data interchange. I like to compare it to the success of XML itself. XML is nothing but a scheme for encoding structured data in a text file. It has thoroughly replaced the Comma-Separated-Values (CSV) format because it can capture heirarchical data structures. Well, the rowset is today the primary format (so to speak) for transferring structured data from a database to a client. By replacing the rowset with an XML stream, we can enjoy the same benefits as with the transition away from CSV to XML. We can now transfer heirarchical (master-detail) data in its natural, normalized state. There are also performance advantages associated with doing so, not the least of which is increased network efficiency and fewer round-trips.
Don't even get me started on the righteousness of defining your DAO using XML Schema (XSD), which forms the center of the SQLXML approach. You can use schema to generate classes, and thus achieve complete Object-Xml-Relational mapping. Note that the Xml itself becomes an implementation detail. That's right, SQLXML provides an excellent foundation for Object-Relational mapping. That is the reason why we regard Microsoft's ObjectSpaces as a competitor to SQLXML. My colleague is particularly concerned:
http://weblogs.asp.net/jcollins/posts/33991.aspx
Let me mention the power and utility of XSLT. If your data is in XML (in this case, a schema definition) you are in a great position. They want a different vocabulary? Fine - transform! XSLT files are succinct, flexible, and resilient (that is, quite stable over time), and can emit non-XML output, like SQL statements. Virtually every project I work on involving XML also involves XSLT.
SQLXML is my favorite SQL Server technology. You wanna talk about it? I'd love to! Mail or reply to this post.