cf.Objective Session - Transfer Caching Mechanisms by Mark Mandel
Posted on May 03, 2008
Mark Mandel covers the theory of caching and what problems it solves and then discusses, in detail, how Transfer addresses caching. The main problem, obviously, is that some aspects of your code can be "expensive" such as retrieving large datasets from the database or converting large data sets into components. Caching addresses this by storing information on disk or in memory so as not to have to repeat the expensive portion of the code.Transfer uses an in memory cache. If you get the same object it generally is retrieved from memory. In addition, an objects child objects will also be retrieved from cache for the most part.
Some issues with caching include overuse of memory and dirty data. You can solve the memory issue by using "memory sensitive caching." A memory sensitive cache tracks how much memory it has available and how many objects it has and determines how many objects it can handle based on that information. As memory becomes more or less available the cache will add or remove objects from the cache. Transfer uses the java.lang.SoftReference object to provide memory sensitive caching. What this means is if no one is actively using the object, the cache knows it can remove this object if necessary.
Transfer also allows you to specify which ColdFusion scope stores the Transfer cache, though by default it is stored in the "Instance" scope. You can configure the maximum amount of objects Transfer caches and how many minutes they are persisted in the cache.
There are a number of algorithms that are commonly used within caching mechanisms such as LRU (least recently used), LFU (least frequently used) and many more. Transfer uses a genetic algorithm whereby each object within the cache pool is given a "fitness score" base upon how frequently it is used and how long it has been in the cache. There is a randomness to the item removed but it is weighted by the fitness score.
Transfer offers mechanisms to manipulate the cache and the objects it contains. The clone API within Transfer allows you to make a copy of an object which can be changed but is not stored in the cache. The cloned object is synchronized when saved. You can manually discard items from the cache using the discard API.
Everything that is cached within an object is stored within a variables scope of an object. If you are using a Transfer Decorator any data that you want cached on a per object basis should be stored in the variables scope of the object. This can help if you have complex operations within the object you can run them once and store them in the memory sensitive cache.
Some problems can occur with the cache when you store objects from the cache is scopes like the session scope. A problem could arise when the object you have stored in session scope has been discarded by the cache. The solution Mark offers is to store the ID of the user in session and then your getCurrentUser() method of your service actually gets by the session.userID. This will utilize the cache an will be less memory intensive on your application because less is stored in session scope.
Comments
There are currently no comments for this entry...be the first!