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/docs/hibernate-jbosscache-guide-3.pdf.)
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@redhat.com_______________________________________________
jbosscache-dev mailing list
jbosscache-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev