views:

116

answers:

3

A couple of Relational DB tables are managed by a single object cache that resides in a process. When the cache is committed the tables are updated. The DB relational tables are updated by regular SQL queries and not anything more fancier like hibernate.

Eventually, other processes got into the business of modifying this object without communicating with one another i.e, Each process would initialize this object (read from DB) and update it( commit to DB), & other process would not know about it holding on to a stale cache.

I have to fix this workflow. I have thought of couple of methods. One is to make this object an mBean. So, the object would reside on one process and every process would eventually modify the object in that process by mBean method invocations.

However, this approach has a couple of problems. 1) Every object returned by this cache has be an mBean, which could make the method invocations quite chatty. 2) Also there is a requirement that every process should see a consistent data model(cache) of the DB, and it should merge its contents to the DB if possible. (like a transaction). If the DB was updated by some other process significantly, it is OK for the merge to fail.

What technologies in Java will help to solve this problem?

+3  A: 

You should have a look at Terracotta. They have technology that makes multiple JVMs (can be on different servers) appear unified. If you update an object on one JVM, Terracotta will update the instance transparently on all JVMs in the cluster in a safe way.

Asaph
Let me ask you this. What would be the memory foot print? Would terracotta maintain multiple copies of the object in multiple JVM's? and update them synchronously? or Would it maintain one copy and give the illusion to the different processes that they have their own copy?
Random Dude
@Random Dude: I don't know the answer to that for sure. My experience with Terracotta is limited to seeing a 2 hour presentation on it from one of the Terracotta guys at the San Diego Java User's Group. I suspect that Terracotta probably keeps the entire object graph in memory on each JVM in the cluster and proxies changes to the other JVMs. But again, I'm not 100% sure about that. Perhaps check in with the Terracotta people directly.
Asaph
A: 

If you wanted to keep the object model, you could use java object cache for centralized storage before committing. Or you could keep a shared lock using zookeeper.

But it sounds like you should really abandon the self-managed cache. Use hibernate or another JPA implementation, which you mentioned. JPA addresses the cache issues and maintains a L2 shared cache, so they've thought about this for you.

John Ellinwood
A: 

I agree with John - use a second level cache in hibernate with support for clustering. Much more straightforward way to manage data by using a simplified data access model and let Hibernate manage the details.

Terracotta Ehcache is one such cache, so is JBoss, Coherence, etc.

More info on Hibernate Second Level Cache can be had here and in the official Hibernate docs on Chapter 19. Improving Performance (note that the while the Hibernate docs do list second level cache providers, the list is woefully out of date, for example who uses Swarm Cache? The last release of that was in 2003)

Taylor Gautier