Brian Stansberry
Fri, 18 Jul 2008 07:21:47 -0700
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() orevict() 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 [EMAIL PROTECTED]
-- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat [EMAIL PROTECTED] _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev