Re: 1), remember that caches are really meant for a read-mostly use case. If your test
stresses the cluster with concurrent writes (i.e., writes 100% of the time) there will be
a degree of deadlocks that occur.
Basically when CacheInstance1 commits a tx, it issues a local prepare (already holds locks
on the nodes) and broadcasts a remote prepare to acquire locks on the other cache
instances.
If at the same time, CacheInstance2 commits a tx ON THE SAME DATA (acquires local locks
before CacheInstance1's remote prepare is received) and attempts to do a remote
prepare, both caches will deadlock since they both want locks on each other's data.
The user guide explains how this works. Here are links to the 1.4.x user guide.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034044#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...