Hi Steve,
Need to touch base with you on the semantics for the JBC 2.0 integration.
1) QueryResultsRegionImpl
In the JBC 1.x impl, the get() and put() operations invoked from
StandardQueryCache suspended any tx before accessing the cache. In the
QueryResultsRegionImpl I've written I do the same, mostly to be consistent.
Good: Locks are not held in JBC for the life of a tx, so you don't get a
tx2 trying to read the cache blocking for a long-running tx1 that cached
a query result.
Bad: That tx2 can see the query results from tx1. Those results might
reflect uncommitted changes made by tx1.
Bad: The tx1 changes are replicated around the cluster as soon as they
are put in the cache, rather than at tx commit. More replication
messages, plus other nodes also see the uncommitted changes.
One possible solution I see to this is to not suspend the tx for put(),
and also pass a 0 ms timeout option to JBC for both get() and put().
Basically, don't block in the face of contention; just timeout and fail
silently. What do you think of this? (Doing this is going to require
addition of a new Option to JBC though.)
2) EntityRegionImpl
I noticed your impl of get() does not suspend any tx, which is different
from the old behavior. So, a get() call will cause a read lock in the
cache that will block any other tx doing an update. Was this intentional?
If it was intentional, it leads to an odd situation when putFromLoad is
called with minimalPutOverride=true
if ( minimalPutOverride && get( key, txTimestamp ) != null ) {
return false;
}
return putFromLoad( key, value, txTimestamp, version );
The get( key, txTimestamp ) call could block, while a regular
putFromLoad won't. So, if minimalPutOverride=true the call might block,
while if minimalPutOverride=false, it won't. That seems odd.
3) TimestampsRegionImpl
Here, suspending the tx on both get() and put() makes total sense. To
ensure the desired async replication though, I'm going to have to add a
new Option to JBC. Until that's done, the timestamps will replicate
synchronously if the timestamps cache is using the same cache as
entities/collections. :(
Good news here is I think I've solved an old problem where async
replication could result in timestamps going back in time.
TimestampsRegionImpl now maintains an internal timestamp map, and just
uses JBC as a replication layer. No change is allowed to the internal
timestamp map unless it *increases* the timestamp.
--
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
