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

[Brian Stansberry]

Galder Zamarreno wrote:
> Paul Ferraro wrote:
>> refresh() always goes to the db, and only potentially triggers a 2LC
>> update - not a read.
>>

[OT] A concern I have is whether the refresh() removes the item from the 
2LC before doing the subsequent Hibernate cache put().  If not our 
putForExternalRead() usage will prevent the new value being placed in 
the cache.

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

Yes.  R_C will be the default config; this stuff is really something to 
document, and to add an alternate R_R config as a convenience for those 
who actually need it. See 
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3390

This whole discussion has me thinking about the use of the OPTIMISTIC 
configs as the default.  The main benefit of OPTIMISTIC is allowing an 
R_R-like semantic without blocking writes. But it comes as a cost. 
(Again, we're talking defaults here, not whether O/L is 'supported'.)

> 
> Hmmmm, this sounds like a bad practice to me or at least not very 
> performant. Evict/clear something within a transaction and then re-get it.
> 

Doing an evict() makes perfect sense in some scenarios (to control 
memory).  Doing a subsequent re-read can easily happen if the logic is 
complex. (Agreed, if it happens a lot that's a sign of a design flaw in 
the app.)  But to then expect R_R from the second read: that for sure 
makes it an edge case.

> Brian, did you use 2nd level cache in your previous use case?
> 

No.

>>
>> 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
>>>>> jbosscache-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> 


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