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

[Brian Stansberry]

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/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