90
Introduction
Database access is usually costly. There is the cost of driving the Database engine. There is the cost of response time in the application waiting for database results. If a particular database result is used often, then caching the results of that SQL call in the application server is a natural requirement to reduce the effect of these costs.
Because the use of database calls is quite common in WebSphere Portal as well as WebSphere Application server, care must be taken to optimize all facets of these SQL calls. In Portal, it is common for the theme as well as Portlets to use database calls therefore caching is imperative here. The most common caching mechanism used in WebSphere is the Dynacache.
A Dynacache is simply a cluster aware Java Hashmap. This Hashmap is cluster aware in the sense that if a “key” is invalidated or updated on one cluster member, appropriate measures are taken on all cluster members to insure that the “value” in the Dynacache Hashmap is either updated or removed as well. The key/value pair can also be inserted into the Dynacache with a time-out value to insure freshness.
So, what are the best practice patterns for the use of a database backed Dynacache instance? This article will attempt to highlight those best practices.
Initial Code
Initially, one can use a simple “dao” (data access object) to fetch the database contents based on some key value. In this example, the key is the “uniqueID”.
DBResults results = dao.getRow(uniqueID);
Obviously, a call to “dao.getRow() “ results in a database access every call. If this call is frequent and uses the same parameter(s), consider caching the result in a Dynacache.
Initial Dynacache Implementation
First, we must create the Dynacache instance along with a JNDI name which applications will use to reference this instance. This is done on the Deployment Manager GUI under "object instances".
To use the new Dynacache instance, the simplest thing to do is to create a Dynacache "impl" class with a "get" method that looks exactly like the call to the database “dao” class' "get" method. It could use exactly the same parameters in most cases.
DBResults results = daoHelperImpl.getRow(uniqueID);
In the new Impl class, check first if the value is in the Dynacache. If not, fetch it. If so, return it:
public DBResults getRow(String uid) {
if (aDynacache.keySet().contains(uid)) {
System.out.println("UID was in the cache");
}
else {
aDynacache.put(uid, dao.getRow(uid));
}
return (DBResults) aDynacache.get(uid); }
Performance Improvements
This is perhaps the most important section of this paper. In a web based application, performance is very important. So, having a version of the Dynacache based database access that avoids repeated accesses to the database is important.
The “impl” class above is a good first pass. However, there is a problem that manifests under load. When there are multiple threads all using the same “uniqueID” and the Dynacache is not yet loaded, you could have lots of thread all trying to write the dao results into the cache if the cache was previously empty.
This problem is resolved by “synchronizing” on the moethod that is used for updating. Kudos to Antonio Fiol Bonnin for finding the error in my original pseudo code.
public DBResults getRow(String uid) {
if (aDynacache.keySet().contains(uid)) {
System.out.println("UID was in the cache");
return (DBResults) aDynacache.get(uid);
}
else {
return checkAndSet(uid);
}
}
private synchronized DBResults checkAndSet(String uid) {
// Handle the case where another thread updated the value while you were waiting
System.out.println("UID was NOT in the cache. Wait for other threads, check to see if then added, otherwise must add");
if (!(aDynacache.keySet().contains(uid)))
aDynacache.put(uid, dao.getRow(uid));
return (DBResults) aDynacache.get(uid);
}
One might see that there is a redundancy here in that the “distributedMap.keySet().contains(uniqueID)” test is duplicated. The reason is simple. Running the test first without the “synchronized” block is much faster and should result in significant time savings if the cache is already loaded. If, however, the cache were empty and this thread was blocked waiting on another thread similarly blocked, it is not clear who wins the race and is first to access the database. You do not want both threads then hitting the database for the same key. It is sufficient for only one thread to actually read the key/value pair from the database and then to update the Dynacache instance.
This implementation insures that only one database access is used to update the key and provides the best performance for all threads as well as the database.
