One thing we did was implement a CacheManager, which gets its CacheProvider based on a configuration setting. We wrote a WebCacheProvider for use in Web applications, and you could equally write some WinCacheProvider or something more specific (EntLibCacheProvider, etc). Our WebCacheProvider uses the ASP.Net caching, of course. (CacheManager and CacheProvider are just classes we created and named, of course).
Just a suggestion as you don't have to use the same caching scheme if you don't want to.
Chris
Andy,
A couple of things to consider.
1. Use the ASP.Net cache.
2. Only cache Read Only objects that are not changed by users. I cache NVLs all the time.
I tried caching a read/write object and served up a clone from the cache but it is not a deep clone and many related BOs inside of it were "changed" and then put back in the cache so users were seeing data input by other users. Overall - a bad idea.
3. Depending on your technology stack you may be able to use SQL Server 2005 database cache invalidation through publish/subscribe.
4. If not, it is fairly straighforward to write your own database cache invalidation mechanism. There are many articles on the topic. I went with a polling solution instead of the "touch a file" solution. The trick is to set up a cache dependency object and then make your NVL in the cache related to it. When the DB is "changed" the dependency object is flushed from the cache (on the next poll interval) and it takes your NVL with it.
Any DB table that you want to track needs a small trigger attached to it that can call a SP to insert a row in a tracking table. The tracking table has 2 columns: tablename and changeid. The SP simply increments changeid for the tablename that was modified. The polling code just selects this tracking table and compares the stored changeid value to the current changeid value. If they are the same, the table has not been modified. If they are different, the table has been modified and the cache dependency object is removed from the cache taking your NVL with it.
Joe
JoeFallon1:
1. Use the ASP.Net cache.
2. Only cache Read Only objects that are not changed by users. I cache NVLs all the time.
I tried caching a read/write object and served up a clone from the cache but it is not a deep clone and many related BOs inside of it were "changed" and then put back in the cache so users were seeing data input by other users. Overall - a bad idea.
No, wasn't planning on caching any editable objects.
3. Depending on your technology stack you may be able to use SQL Server 2005 database cache invalidation through publish/subscribe.
Thats one I had forgotten about. How have you integrated this with Csla (if you have)? I have a DAL which hides the db server specifics, so this might be a bit more challenging, but I'm sure I could figure something out.
4. If not, it is fairly straighforward to write your own database cache invalidation mechanism. There are many articles on the topic. I went with a polling solution instead of the "touch a file" solution. The trick is to set up a cache dependency object and then make your NVL in the cache related to it. When the DB is "changed" the dependency object is flushed from the cache (on the next poll interval) and it takes your NVL with it.Any DB table that you want to track needs a small trigger attached to it that can call a SP to insert a row in a tracking table. The tracking table has 2 columns: tablename and changeid. The SP simply increments changeid for the tablename that was modified. The polling code just selects this tracking table and compares the stored changeid value to the current changeid value. If they are the same, the table has not been modified. If they are different, the table has been modified and the cache dependency object is removed from the cache taking your NVL with it.
Copyright (c) Marimer LLC