brady gaster

I have two issues with the new database caching and only one of them was addressed by the article...

1) Polling the database every few seconds? I thought the whole point of caching the data was to reduce hits to the database not increase them....granted it's a smaller hit but quite a bit of them....I actually got this working in .NET 1.1 and it really is an inefficient way of doing things....The push model in Yukon will be really tight though....*THAT* I would be interested in looking into further, but the pull model just seems like a hack.

2) All of the database caching techniques are limited to SQL Server? This is the impression I get from the article, and I don't know about everyone else but SQL Server isn't the most prominent db in use today....I'd like to be able to use this feature when accessing my Oracle databases as well....kinda kills the idea unless you're an entirely MS shop....

I had really high hopes about this feature when I first heard about it, but once I researched it more I just found the implementation lacking....the push method is what I was expecting, but seeing as how it's going to be a while before adoption of Yukon by my company it looks like I'm going to skip this feature and continue to use the xp_cmdshell extended stored procedure through a trigger to update a file dependency....

I would like to address the issue of tight coupling with SQL Server. One thing to keep in mind is that it is still possible for a developer to write a custom cache dependancy mechanism and support different databases such as Oracle and so on.


However I agree with you in that the pull model is not an efficient approach.