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

[Brian Stansberry]

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
[EMAIL PROTECTED]
https://lists.jboss.org/mailman/listinfo/jbosscache-dev



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