Hi,
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 :-).
Thanks in advanced.