Stomp

Adding an efficient data cache.

Stomp and Kodo combine to provide simple and powerful caching options. Here’s how to configure Stomp to take advantage of this synergy.

Stomp keeps one “read-only” data cache, which loads data from the database once, then saves this information for later use. When used in an appserver or other long-running JVM, this can be a tremendous performance enhancer. The question is: how do you keep this cache in sync with the database? Here are some options:

Single JVM cache management. It is easy to configure Stomp to reread objects from the database whenever a change is committed in another transaction. A Kodo data cache which implements this behavior is provided for you: stomp.jdo.kodo.UpdatingCache. All you have to do is tell Kodo to use this DataCache internally. To do this, edit your kodo.properties file to look like this:

com.solarmetric.kodo.LicenseKey: your-kodo-license-key-here

javax.jdo.PersistenceManagerFactoryClass: com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory

javax.jdo.option.ConnectionURL: your connection info here

javax.jdo.option.ConnectionUserName: your db username here

javax.jdo.option.ConnectionPassword: your db password here

javax.jdo.option.ConnectionDriverName: your.jdbc.driver.Here

javax.jdo.option.NontransactionalRead: true

javax.jdo.option.RetainValues: true

###### Data cache management prefs ############

com.solarmetric.kodo.DataCacheClass: stomp.jdo.kodo.UpdatingCache

com.solarmetric.kodo.DataCacheProperties: schemaGroup=stomp

com.solarmetric.kodo.RemoteCommitProviderClass: com.solarmetric.kodo.runtime.event.impl.SingleJVMRemoteCommitProvider

com.solarmetric.kodo.RemoteCommitProviderProperties: Topic=topic/KodoCacheTopic

################################################

com.solarmetric.kodo.PersistenceManagerClass: stomp.jdo.kodo.KodoPMWrapper

com.solarmetric.kodo.PersistenceManagerProperties: schemaGroup=stomp

Anything in bold needs to be added to your properties file to integrate Kodo with Stomp. Note in particular the two schemaGroup configurations passed to the DataCache and the KodoPMWrapper. Stomp is the default schemaGroup, but if you are using multiple databases in the same JVM, you’ll have to change this to match your chosen schemaGroup names.

Multiple JVM distributed cache. Kodo makes this a trivial change. Just change the RemoteCommitProvider property to describe the class which is going to distribute changes. Kodo provides several default implementations, including a JMS distribution class, which you can use. See the Kodo docs for more details on these distribution classes.

Note that a persistent change in one JVM will result in a RefreshManager callback in all the JVMs in the cluster (cool).