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