Best locking strategy

bentins Dec 4, 2008 7:10 AM

I have an existing ejb 2.1 application which I now moved to clustering.

If I understand the documentation correctly 2.1 entities are not shared on the cluster through a common cache.

This means that if two users running on two different nodes are working on the same database row through an entity bean they may corrupt the data?

If so, I tried to use row-locking on the entity which creates a "SELECT FOR UPDATE... " queries on the db and thus locks the row when a transaction is working on it. But with this I have problems on ejb queries that use "DISTINCT, MAX, MIN or SUM" and since I have such queries it does not look like a good solution.

Can someone please help here on what is the best strategy? Should I try to use optimistic locking on all beans? Did I understand the documentation wrong?

THX

1. Re: Best locking strategy

brian.stansberry Dec 11, 2008 11:09 PM (in response to bentins)

Correct; entities are not shared on the cluster through a common cache. There is a cache invalidation framework (CIF), through which messages can be sent around the cluster to invalidate the local caches on each node.

Some of the older versions of the clustering docs actually have better coverage of the CIF than the newer ones. See the Cache Invalidation section of http://docs.jboss.org/jbossas/clustering/JBossClustering7.pdf . In particular, have a look at the "Use Cases" section starting on page 98, where a pattern of having a read-only version of a bean along with a read-write version is described. Perhaps this will help with your use case.
Actions