Re: [jbosscache-dev] READ_COMMITTED should be enforced for Hibernate 2nd level caching?
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