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

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