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