[hibernate-dev] JBoss Cache 2.0 Integration

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(a)redhat.com