On Wednesday 05 September 2007 01:48:31 pm James Carman wrote: The very first thing I would do is to split the roles currently filled by FromElement into two separate node types (one for the join and one for the persister reference) because currently this is all munged together. It'll make this easier to work with. The big difficulty is somehow tracking the property references as they are being resolved so that you know what is the right side and left side of the join. This whole problem is easier to solve when we move from 3 phases to 4 phases, which is the reason this was put on the back burner in the first place. There is a branch where i started prototyping some of this work: http://anonsvn.jboss.org/repos/hibernate/core/branches/HQL_ANTLR_2/ You might want to take a look there for some ideas.

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