[hibernate-dev] JBoss Cache 2.0 Integration

[Brian Stansberry]

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
brian.stansberry at redhat.com