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#4034044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034044 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
