JBossCache concurrent transaction management

[aricci]

Hi everyone,
i am trying to understand how concurrent transactions are managed by JBossCache. I have developed a simple EJB3 application that i am testing on a cluster of JBoss-4.0.5 instances. it creates a certain amount of threads that perform concurrent modification and creation of EntityBeans on different nodes of the cluster, sharing a common DB (PostgreSQL-8.2.1).

several scenarios have arised when two transactions try to concurrently create the same EntityBean on different nodes of the cluster:

1) sometimes they stop their execution till a timeout expire (ERROR [IdentityLock] write lock for /server/Book/server.Book#4 could not be acquired after 15000 ms), when one of them is able to committ its transaction. it looks like both are waiting the other to acquire lock: a deadlock that is broken only when timeout exception arises.

2) sometimes one of them is aborted because of duplicate key violation (ERROR: duplicate key violates unique constraint "book_pkey". ERROR [JDBCExceptionReporter] Batch entry 0 insert into BOOK (TITLE, AUTHOR, ID) values (Fiesta, Hernest Hemingway, 5) was aborted. Call getNextException to see the cause.).

3) sometimes one of them is aborted beacuse of PersistenceException (ERROR: PersistenceException, org.hibernate.PersistentObjectException: detached entity passed to persist: server.Book).

what i don´t understand is:
- why exception (1) arises?
- what is the difference between exception (2) and (3)? is that in exception (2) transaction is aborted at DB level, when performing INSERT operation, instead in exception (3) it is aborted at AS level, when creating the EntityBean?

finally i would like to know if it exists a document where it is deeply described how transactions are managed by JBossCache inside a cluster.

many thanks
Andrea

[aricci]

i forgot to specify my JBossCache (version1.4.0.SP1) EntityBeans configuration:
- NodeLockingScheme: PESSIMISTIC
- IsolationLevel: REPEATABLE_READ
- CacheMode: REPL_SYNC

Andrea

[manik]

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.