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

[Paul Ferraro]

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