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
[EMAIL PROTECTED]
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
_______________________________________________
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]
_______________________________________________
jbosscache-dev mailing list
[EMAIL PROTECTED]
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Manik Surtani
Lead, JBoss Cache
[EMAIL PROTECTED]
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
