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 > [EMAIL PROTECTED] > https://lists.jboss.org/mailman/listinfo/jbosscache-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
