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

[Manik Surtani]

On 17 Mar 2009, at 14:29, Brian Stansberry wrote:

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

Sure

>
> 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
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik at jboss.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20090317/014d3217/attachment.html