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

Paul Ferraro wrote: > 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.

Hmmmm, this sounds like a bad practice to me or at least not very performant. Evict/clear something within a transaction and then re-get it.

Brian, did you use 2nd level cache in your previous use case?

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