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

[Galder Zamarreno]

Paul Ferraro wrote:
> refresh() always goes to the db, and only potentially triggers a 2LC
> update - not a read.
> 
> 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.

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.

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

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

-- 
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat