> All nodes are connected to single database.
> The commit option for Entity Beans is B. If two
> entity beans from two different nodes try to update
> same row at same time in the database, then what will
> happen?

Each node runs a TX against the database, which results in one of the 2 nodes getting access, and the other one having to wait until it is its turn. The first node then completes the TX, writes its data back to the DB and removes the object from the cache (as you use commit option B). Then the second node will be able to acquire the DB locks and can proceed.

The bad thing about commit options B and C is that they essentially don't allow caching in a cluster.

If your app is able to tolerate a bit of stale data, then you might look into using commit option D, which does use caching, but removes cached entity beans after some preconfigured timeout.

Also note that JBoss 4 will have a transactional cache in front of the entity beans, which will allow us to cache entity beans forever, or until cache size requirements evitct beans from cache.


> How to share a single data source across all nodes?
> What is the best way to deal this problem?

You're doing the right thing. With the current clustering architecture it is the only way to go.

Bela