[hibernate-dev] Re: [jbosscache-dev] REPEATABLE_READ in JBC as Hibernate 2nd Level Cache
Manik Surtani
manik at jboss.org
Fri Jul 18 05:49:39 EDT 2008
AFAIR the last time we discussed this (last summer in Austin with
Steve and Gavin) we came to the conclusion that R_C was optimal for
the 2LC use case.
On 17 Jul 2008, at 22:59, 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.
You'd need to check with Steve on this, but to the best of my
knowledge, once a session has started, it copies stuff to a "first-
level cache" which is a Map associated with the session. A
Session.clear()/evict() would only flush the 2LC, the 1LC would still
be intact to provide R_R to the caller. Although it does sound a bit
odd that a clear() or evict() won't affect 1LC and go straight to 2LC,
so I could be wrong. :-)
Cheers,
Manik
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org
More information about the hibernate-dev
mailing list