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

[Manik Surtani]

On 18 Jul 2008, at 16:35, Brian Stansberry wrote:

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

Either way this should be tested.  In the cache-jbosscache2 module in  
hibernate-core, probably.

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

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