READ_COMMITTED is the recommended isolation level for the Hibernate Second Level Cache use case[1], since the Session itself acts as a R_R cache. The reason you'd use R_R in JBC is if your app was calling Session.evict() or Session.clear() and then you wanted to re-read an entity with R_R semantics.
Manik, why is the removeNode call not removing the node? Is the MVCC code detecting that the node didn't exist when the get() call happened and therefore turning the removeNode into a no-op? dukehoops, there's also a race at work here if there are multiple threads involved. See http://opensource.atlassian.com/projects/hibernate/browse/HHH-3817. To deal with that I think I need something more sophisticated in the Hibernate/JBC layer such that a call to org.hibernate.cache.Cache.evict(key) results in pending putForExternalRead calls being ignored. Basically turn get() + pfer() into a logical single operation that gets aborted if an evict happens in the middle. That's not so nice though, adds overhead. [1] See page 13 of http://www.jboss.org/file-access/default/members/jbossclustering/freezone/docs/hibernate-jbosscache-guide-3.pdf View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218687#4218687 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218687 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
