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

[Brian Stansberry]

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 at redhat.com