Caching read-write data in Java

Creator PDF 417 in Java Caching read-write data

Suppose you want to cache objects that are of a changing nature. You must do this with caution; if you have a high-transaction environment, you may find that your

cache is overburdened and effectively useless. The reason for this is that an attempt to keep high-transaction data cached would require that you flush the cache often. Flushing the cache too often could create a twofold burden. First, your application would constantly be in a state of checking the cache, clearing the cache, and repopulating the cache on every request to the database. Consequently, if the cache is constantly being cleared, this means that the database is also being hit to retrieve fresh results. You ll come to a point where it is simply better for performance if you use database techniques such as indexing and table pinning and avoid application-based caching. Even though you need to be careful when caching data that may change, it also makes sense to do so when the data is of a less volatile state. In the JGameStore application, we find a good example of this with caching products. With many storefronts, there is a need for administrators to enter new products, update existing ones, mark others as sale items, and similar tasks. These kinds of activities will produce a mild level of volatility. Since this is not a high-transaction environment, caching can play a role in improving overall application performance. As long as the cache has time to build up and provide users with improved performance over a span of time, you will avoid the sinkhole described previously. When examining the nature of the data that you want to cache, consider several factors:

The number of products will likely be significant. The products data is of a changing nature. The products that are most often accessed will change throughout the day depending on consumer habits.

In our example, we decide to use the WEAK memory cache because it is a less restrictive means of caching. Unlike LRU, which requires a certain level of predictability for determining the number of results that should be cached, the WEAK memory cache allows us to decide which items to retain and discard before a predetermined artificial limit is met. Since the cache uses the java.lang.ref.Reference implementations to store data in the cache, it can remove or retain results based on internal analytics. When using the WEAK reference type with the MEMORY cache, the results are wrapped with a WeakReference (java.lang.ref.WeakReference) and stored in the cache. Then, the garbage collector is able to handle the wrapped results at its discretion. Now let s move on to configuring the <cacheModel> tag. As expected, the cacheModel type attribute is specified as MEMORY. Note that we are setting the

readOnly attribute on the <cacheModel> tag to true in an environment that is a read-write environment. Additionally, we set serialize to false to eliminate the

burden of the deep copy. That means that objects that are retrieved from the cache may be altered. This is a safe approach for several reasons. First, only the person managing the cart will be altering product objects. The users who are actually shopping will never change the product object through their actions. Second, whenever a product update occurs, the cache is flushed. Finally, specifying the reference-type property as WEAK will not allow products to hang around very long because it discards them at the discretion of the garbage collector. Listing 9.10 shows an example of our cache model configuration.

<cacheModel id="productCache" type="MEMORY" readOnly="true" serialize="false"> <flushOnExecute statement="Product.add" /> <flushOnExecute statement="Product.edit" /> <flushOnExecute statement="Product.remove" /> <property name="reference-type" value="WEAK" /> </cacheModel>

We can now use the defined <cacheModel> from a query mapped statement. We tell the getProductById query mapped statement to use productCache by specifying it in the cacheModel. Whenever the getProductById select is called from the application, the cached product object will be retrieved according to the specifications of the productCache cache model. Listing 9.11 shows a simple example of how a <select> statement can take advantage of the defined <cacheModel>.