JBossDeveloper

Brian,

I found the answer in IdentityLock jboss cache class:

1- If the transaction already has a read lock on the entity (which is acquired by an EntityManager.find() ) the read lock will be INMEDIATELY upgraded to write lock, EVEN if there's a concurrent transaction which already has a read lock on the same entity.

2- If the transaction performs a EntityManager.createNamedQuery(), then it does not have any read locks on any of the entities returned by the query, so if the transaction writes to an entity which is read locked by another concurrent transaction, then the write lock will block till the transaction with the read lock on that entity commits.

Point 2 is what is described in the hibernate doc. But I think point 1 is confusing, don't know if a bug.

Just to remember,

test case is T1 and T2 concurrently reading and entity from cache and T2 writing(modifying) that entity. I've tested 4 cases, which answers your question:

1.- PESSIMISTIC, R_R, T1 and T2 reading the entity from cache with em.find(). When T2 tries to write the entity the RL is upgraded to WL. T2 DOES NOT BLOCK till T1 commits.
2.- PESSIMISTIC, R_C, T1 and T2 reading the entity from cache with em.find(). Same behaviour as 1.
3.- PESSIMISTIC, R_R, T1 reads the entity with em.find(), T2 reads a set of entities with em.createNamedQuery(). Since T2 does not have a RL on the entity, T2 BLOCKS trying to acquire a WL till T1 commits. Then T2 proceeds.
4.- PESSIMISTIC, R_C, T1 reads the entity with em.find(), T2 reads a set of entities with em.createNamedQuery(). Same behaviour as 3.

Only test case 3 complies with what's written in the hibernate guide.
Also, READ COMMITTED semantic is being overwritten by Hibernate 1st level cache. That's why a re-read in T1 of the same entity (after T2 commited) will always have R_R semantics.

BTW: JBC version is 3.0.2. I'll be testing the same with MVCC and let you know.!!

Gooossshhh,

I'm sorry Manik. I decided to test it all again and pay better attention to the traces.

EVERYTHING is working fine, I mean, R_R semantic DO BLOCK writing if a reader already holds the lock. R_C allows writers to proceed, EXACTLY as described in hibernate guide.

Thanks for your support that took me to a better knowledge of the cache.
BTW, don't take this error into account and please keep on answering my future questions ;-)

Thanks again.