[hibernate-dev] Re: [jbosscache-dev] REPEATABLE_READ in JBC as Hibernate 2nd Level Cache

[Brian Stansberry]

Manik Surtani wrote:
> 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.
> 

Yep. I was looking for reasons to flat out say "never use R_R, always 
R_C" in docs and such. Seems it's a bit more subtle than that.

I did neglect to change the default in the AS 5 / Hib 3.3 config files, 
which will shortly be corrected.

> 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.  :-)
> 

Session.evict() and clear() clear the 1LC.[1]  The 2LC is managed via 
the SessionFactory API.

In my now-recollected usage of Session.evict() at my previous employer, 
we used it to free memory during transactions that processed a lot of 
data, exactly what [1] describes.

So, so far it seems R_R in the cache config only makes sense if:

1) You are using Session.clear() evict() or refresh().
2) AND your app needs R_R semantics for the entities/collections 
affected by those calls.

AIUI, the whole point of using refresh() is because you don't want R_R 
semantics [2], so clear() and evict() are the key points.

[1] 
http://www.hibernate.org/hib_docs/v3/reference/en/html/performance.html#performance-sessioncache
[2] 
http://www.hibernate.org/hib_docs/v3/reference/en/html/objectstate.html#objectstate-loading

> Cheers,
> Manik
> 
> -- 
> Manik Surtani
> Lead, JBoss Cache
> manik at jboss.org
> 
> 
> 
> 
> 
> 


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com