In the semi-static tests, the fetch assumes that the cache is up-to-date because the update method refreshes the cache. A problem with this solution occurs when the update isn’t done through this update method (but directly in the database, for example) or when you need to use a farm of servers. Support for aging views in LookupTable is a good solution (if real time consistency isn’t needed) and it’s easy to build something similar, for example, for the SPM too.
Another approach could be to check before using the cache to see if it is up-to-date, for example by comparing timestamps between the database and the cache. The drawback here will be that the database still needs to be touched anyway.
Yet another solution could be to not put the cache on each machine in the farm but to have it on a dedicated machine and communicate with it by DCOM. This is usually not a very good idea since the communication cost will be high.
There are of course several other algorithms. Combine your requirements for real-time consistency with your imagination.
One common trap you can get into when trying to keep state at the server-side is using the VBScript dictionary object found in scrrun.dll. Unfortunately that component is not agile, and to make things even worse it has been marked as such in the installation process. The component isn’t thread safe which will give problems after a while when used in a context where thread safety is expected. (See msdn.microsoft.com/workshop/management/planning/MSDNchronicles2.asp for more information.)
Another common trap is trying to save Visual Basic objects in the SPM. Visual Basic objects have thread affinity which means that they can only be used by the thread that instantiated them. (Don’t you want to have Visual Basic .NET now?) When another thread tries to use the object, there will be a crash.
Remember that if you use configured transactions in COM+, you will work with SQL Server with the transaction isolation level set to Serializable. Then it’s not a good idea to accept a low consistency level for the cache if it’s used in a transaction!
OTHER PERFORMANCE IMPROVEMENT OPTIONS TO CONSIDER
Well, this is an enormous topic that I have only touched upon in this article. For example I haven’t talked much about using XML documents for the cached data. (Can you write an article these days without talking a lot about XML<g>?)
Perhaps you wonder why you shouldn't always transform
data to HTML and store the HTML-string in ASP.Application? That is certainly a very good solution, but there are scenarios when it's not the correct way to go: