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

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.

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 >