I am not sure if this question should go in this topic, so please move accordingly.
In the application that my team is trying to build, we have come up to a problem that we need to find a solution to. Below is listed the problem as clearly as I can. Please ask if further clarification is needed.
We have a complete J2EE application that we want to do trivial clustering on across multiple computers. By trivial clustering, I mean we take the entire application and replicate it across multiple computer, each instance exists in its own app server. This does not involve distributed objects.
However, we have some data that we need to cache in the app server. This data can be updated. Whenever it is updated, the parts that read the data need access to the updates right away. To do this, we initially are thinking of using Hibernate and enabling its secondary cache. This would allows us to persiste the data to a database while at the sametime caching those changes for the components that need the data.
We are trying to decrease database access to writes only as there are too many reads for the database to handle. Therefore, we want to have writes persisted to the database and reads to be done against an in memory cache. Both must be updated at the same time. Hibernate seems to fit the bill for this.
However, once we move to a clustered environment, we still need to update and synchronize this data across app servers. So if an object is updated on app server 1, that updated must be propogated to all the other app servers.
We do not want to make the jump to entity beans and a proper distributed computing model in order to accomplish this. There must be a simpler method.
One possibility that we have thought about is to use JMS and the observer pattern to notify the other app servers that their data is dirty, thus forcing the other caches to do an update fromm the DB.
Are there other ways of doing this? Can Hibernate be successfully used in a clustered environment? Any thoughts or ideas are welcomed, including telling me that we are idiots for thinking about this :-).
I do not have clear answer, however I can give you more thoughts. We use multiple instances approach with event channel to notify about changes. However, there is some time between change and actual cache updating, so there is a possibility when some instance will use dirty data. It's Ok for our case, but I do not know about yours. To solve the problem you may apply a lock for caches before starting update, however it can slow down system.
I was looking through the Hibernate in Action book and I think using JBossCache with transaction caching might just do the job for us. I will have to experiment with it though. Does anyone have any experience using JBossCache across a cluster?
Google for Java distributed cache. There are a bunch of products out there. There is a JSR headed by one of the top guys at Tangosol but I think it's stalled.
My application uses JMS notification two ways. One is to send the key and a command to set the key dirty or remove it from cache. The next time somebody needs the value they have to go to the database and reload the cache. The other is to send actual data that never goes to the database. It is in memory only.
In both cases the clone that does the data change broadcasts the message and receives its own message and does exactly what the other clones do.
In the second case, I frankly don't know how a new clone starting up gets in sync with others that may have been running for hours. It's deep in a vendor framework, but probably worth digging into one day.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi