Re: [jbosscache-dev] READ_COMMITTED should be enforced for Hibernate 2nd level caching?

I'm about to post my comment re: R_R on the forum. Can we continue the discussion of this issue there, as dukehoops has done a lot of research and I don't want to drop him out of the discussion.

Brian Stansberry wrote: > Jason T. Greene wrote: >> Manik Surtani wrote: >>> Have a look at this thread: >>> >>> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218569 <http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218569 >>> > >>> >>> Does it make sense to enforce READ_COMMITTED for the Hibernate >>> 2nd Level Cache provider for JBC3, if MVCC is used? >> >> I would agree that REPEATABLE_READ does not make sense for a >> second level cache. >> > The only logical use for R_R in the second level cache case is if > someone uses the Hibernate Session.evict(Object) method to evict an > entity or Session.clear() to clear all entities, and then later in > the tx wishes to read the entity again. Otherwise the Session > itself acts as a R_R cache. > (This is covered on page 13 of http://www.jboss.org/file-access/default/members/jbossclustering/freezone....) >> However, this sounds like a problem with PFER. If someone calls >> PFER, I think the original transaction should resync the node >> snapshot. > How would this be done? AFAIK the application has no control over > the data in JBCs transaction context. > In other >> words, the application has already attempted to write a new value >> (in the same thread and source tx even), so RR isolation is not >> only unnecessary, it is inconsistent with expectations. >> -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev