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.!! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223429#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...