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

[Paul Ferraro]

refresh() always goes to the db, and only potentially triggers a 2LC
update - not a read.

Perhaps we should revisit whether the scenario below warrants the cost
of repeatable_read, given that entity eviction from session cache is
typically used only to minimize memory usage when iterating through
large results, i.e. when an entity is not likely to be re-read within
the current transaction.

On Thu, 2008-07-17 at 16:59 -0500, Brian Stansberry wrote: 
> 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
> > 
> 
>