This becomes a maintenance nightmare as your project grows.
#SAVE DATABASE OBJECT IN ICOLLECTIONS CODE#
Imagine writing this kind of code over and over again for each and every entity that you want to cache. var pagesOfUser = _database.GetList(.) Ĭache.Add((page.ID), page) Need to load collection from database and then cache it. ResultantPages.Add(individualPageInCache) If each item in the collection is no longer in cache, invalidate the collection // and load again. Var cachedPages = cache.Get(cacheKey) as List If you want to cache the collection of Page for a user as well as cache individual Page objects so that each Page can be retrieved from Cache directly, then you need to write code like this:Ĭopy Code public List GetPagesOfUserOldSchool(Guid userGuid) For example, say you are loading a Page collection that belongs to a user. If you are doing it the conventional way, you will be writing a lot of repeated code in your data access layer. If you load the collection from cache only, then the collection will contain the stale object. So, you expired it in cache so that on next retrieval it comes from database. For example, something changed in the object or the object has been deleted. An item in the collection may have been force expired in cache.This is why each item needs to be retrieved from cache separately. So, if you get the collection from cache and return as it is, you will get stale individual items inside that collection. But the collection, which contains all those individual items has not been refreshed. An individual item has been updated and the updated item is in cache.You might be thinking why do we need to read each individual item from cache and why do we need to cache each item in collection separately when the whole collection is already in cache? There are two scenarios you need to address when you cache a collection and individual items in that collection are also cached separately: database) and cache each item in the collection separately. No, discard the whole collection from cache.Yes, get the individual object from cache.Is that object individually available in cache?.Is the collection being requested already in cache?.Then the caching logic gets more complicated: But each User object is also cached separately because you need to load individual User objects frequently. For example, say you have cached a User collection. On the other hand, when you are dealing with cached collection where each item in the collection is also cached separately, then the caching logic is not so simple. No, then load it from database and then cache it.Is the object being requested already in cache?.In such a case, you write simple code like this: Sometimes the caching can be simple, for example caching a single object which does not belong to a collection and does not have child collections that are cached separately. Common Approaches to Caching Objects and Collections It’s a quick win to make your application a lot faster than doing complex re-engineering in your application. If you are suffering from poor page load performance and high CPU or disk activity on your database and application server, then caching Top 5 most frequently used objects in your application will solve that problem right away. It shows clearly the significant difference it can make to your application. During the load test, CPU utilization was around 60%. Page load time decreased significantly as well to 0.41 sec only. The average page response time is 1.44 sec.Īfter implementing caching, it became significantly faster, around 32 requests/sec. Here data is loaded from database as well as from external sources.
#SAVE DATABASE OBJECT IN ICOLLECTIONS 64 BIT#
Dropthings – my open source Web 2.0 AJAX portal, without caching can only serve about 11 request/sec with 10 concurrent users on a dual core 64 bit PC. Here’s an example how caching significantly improves the performance and scalability of applications. It’s a library that helps you get rid of thousands of lines of repeated code from a medium sized project and eliminates plumbing (logging, error handling, retrying, etc.) type code completely. Here I will show you how you can make the caching a lot easier using LINQ to SQL and my library AspectF. The more code you write, the more maintenance overhead you add. Your data access layer gets a whole lot of code that deals with caching objects and collection, updating cache when objects change or get deleted, expire collections when a contained object changes or gets deleted and so on. However, implementing caching is tricky and monotonous when you have to do it for many classes. When objects are cached, they can be retrieved from the cache which is a lot faster and more scalable than loading from database, file or web service. Caching of frequently used data greatly increases the scalability of your application since you can avoid repeated queries on database, file system or to webservices.