Browse DevX
Sign up for e-mail newsletters from DevX


Server-Side Caching in COM+ and VB : Page 7

Are there times when server-side caching is a good idea? How does server-side caching impact data access performance? Testing the various techniques seems to be the only way this can be determined. Thats what this article is all about. It examines and shows test results for COM+ techniques that are VB-friendly such as using the Shared Properties Manager, using the file system, and using global variables, a lookup table, the Global Interface Table, and commerce.dictionary, and compares these techniques to the caching performance of going to the database each time for data and the baseline when no data is read. Then the article looks at other algorithms and caching options you might want to consider. Also provided with the article is a tool you can use for your own tests.




Building the Right Environment to Support AI, Machine Learning and Deep Learning


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!


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:

Jimmy Nilsson is the owner of the Swedish consultant company JNSK AB (www.jnsk.se). He has been working with system development since late 1988 (with VB since version 1.0) and, in recent years, he has specialized in component-based development, mostly in the Microsoft environment. He has also been developing and presenting courses in database design, object-oriented design, etc. at a Swedish University for six years. Jimmy is the author of ".NET Enterprise Design with Visual Basic .NET and SQL Server 2000" and he often speaks at VSLive conferences.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date