A Java cache for OSB

http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ConcurrentHashMap.html

ConcurrentHashMap is a Thread-safe implementation of a HashMap, optimized for concurrent reads and writes scenario.

You can expose a ConcurrentHashMap as a Static attribute of a Java Bean, accessed by OSB Message Flow via Java Callout or Custom XPath.

cache (the individual cache) is a HashMap - where String is the Object Key (e.g. the userId), and XmlObject is the corresponging cached response (e.g. the User object). A Cache will contain homogeneous objects (XmlObject of the same type).

caches (collection of cache) is a HashMap, where String is the Cache Name (e.g. "USERS")


caches.get("USERS").get("1234") will return the XmlObject describing user 1234


caches.clear() will remove all caches
caches.get("USERS").clear() will clear an individual cache

Caches can be cleared with a REST Proxy Service http://myhost:myport/CacheService/ClearCache/USERS
One can use a cron job with a wget command to clear them periodically

One can add metainformation to a Cache, such as the creation time, the last update time, the last access time...

One can expose management of the Caches via JMX (registering the MBeanAgent into the Weblogic or JVM MBean tree), and administering via JConsole or any other JMX-Enabled tool.

The advantage of storing an XmlObject in cache is that it doesn't require conversion inside OSB, since OSB stores complex variables in XmlObject format.
In Coherence the object would be stored in POF format - requiring further materialization to XmlObject format

Coherence cache: read-through, write-through....

http://wiki.tangosol.com/display/COH33UG/Read-Through,+Write-Through,+Refresh-Ahead+and+Write-Behind+Caching



the presentation is very complete but slightly complicated...

DS=datasource.

in simple words:

read-through: if hit -> return; if miss -> fetch from DS, put in cache and return


refresh-ahead: tries to improve read performance by reloading from the DS the frequently requested data which are about to expire (better performance in reads)


write-through: upon put, store in cache, store in datasource and only then return (bad performance)


write-behind: upon put, store in cache and return immediately; you will update the DS later
(better performance in updates)


I have the sensation that cache synchronization problems can become really nasty when one tries to optimize stuff in a frequently updated cache... this is why you need Coherence experts, you can't improvise.