Ooops I forgot another couple of questions: - I'm testing the cache with PESSIMISTIC and both RR and RC. - I understood from Manik that RC does not make any sense since hibernate session provides RR. - But according to the document you pointed me to (hibernate-jbc), "pessimistic locking with REPEATABLE_READ will cause a write to block if there is a concurrent transaction which holds a read lock, till the read transaction commits".
I tested the following which leads me to a different interpretation. - T1 and T2 reads an entity which has been previously cached. T2 starts slightly after T1. - T1 then just waits ..... and T2 modifies a field of the read entity and commits (I see the cache and db updated). - Then after a while T1 prints the same field T2 modified, and commits. The two reads of T1 reports the same value (this is consistent with RR policy) but I don't see T2 blocking till T1 commits, which according to the document should be the case if OPTIMISTIC is used. I'm sure I'm missing something "again" ;-) . View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222716#4222716 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222716 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
