[hibernate-dev] Re: [jbosscache-dev] REPEATABLE_READ in JBC as Hibernate 2nd Level Cache

[Brian Stansberry]

Hmm, good point. Potentially also Session.refresh(...), although I'm not 
sure if the implementation of that method skips the 2LC and goes right 
to the db.

Paul Ferraro wrote:

> After thinking this through, the only scenario I can think of where the
> 2LC would be subject to a repeated read is after a session cache
> eviction (i.e. via Session.clear() or Session.evict(...)).  Without
> REPEATABLE_READ isolation on the 2LC, any subsequent request withing the
> same transaction for an evicted entity could return an updated value, if
> the cache was updated by a concurrent request.
> 
> Paul
> 
> On Thu, 2008-07-17 at 12:59 -0500, Brian Stansberry wrote:
>> Can anyone see a reason to use REPEATABLE_READ as the JBoss Cache 
>> isolation level in the 2nd level cache use case? I'm not seeing one, and 
>> it certainly hurts performance by forcing cache writes to block waiting 
>> for an earlier tx that did a read to commit.
>>
>> There are 4 types of data cached:
>>
>> 1) Entities
>>
>> If an entity is read from the 2LC, for the life of the tx it will be 
>> cached in the Session, so AIUI there should be no second read during the 
>> tx. So no benefit to RR.
>>
>> 2) Collections
>>
>> Same as entities.
>>
>> 3) Queries
>>
>> If an application executes a query twice in the same tx, I wouldn't 
>> think they'd expect the same result. In any case, if an update to the 
>> query cache is blocking waiting for a tx that previously read the query 
>> result to release, the existence of the  update that means the 
>> underlying entities and their timestamps have changed. So a repeated 
>> read of the cached query will just result in it being discarded as out 
>> of date anyway.
>>
>> 4) Timestamps
>>
>> Here you don't want an RR semantic. You always want to get the most 
>> up-to-date data.
>>
>>
>> Anyone see any holes in my thinking?
>>
>> --
>> Brian Stansberry
>> Lead, JBoss AS Clustering
>> JBoss, a division of Red Hat
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> 


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com