"bstansberry(a)jboss.com" wrote : | Re: 2) | The discussion above may remove the DataVersion issue. The DataVersionProvider interface allows me to ensure the correct DataVersion is applied to the resident node. I say "may" because it only solves the problem if the DataVersion is properly passed around the cluster, works with invalidation etc. Haven't thought hard about that. | | Further, looking at the analysis of data versions on this thread, I think what is really needed for the Hibernate case is to disable the data versioning for OL. That is, allow configuration of a cache-wide DataVersionFactory, where Hibernate would configure a factory that returns its NonLockingDataVersion. There doesn't seem to be any advantage to actually doing version validation. Either Hibernate will catch any version conflict at the DB level before the JBC beforeCompletion() callback gets invoked, or a PFER will see any existing node and abort. | Correct. The question is, how important is it that we add this for optimistic locking in 3.0? As far as possible I'm trying not to touch OL and PL code in this release, the focus being to promote MVCC since both OL and PL are conceptually broken in certain ways. As a workaround, you could use a NonBlockingDataVersion in an option for ALL calls that touch any nodes in the OptimisticCacheProvider. "bstansberry(a)jboss.com" wrote : | Re: 1) | | TBH, I'm not sure if there's any reason I care about the node being marked "resident" other than its relation to the DataVersion issue. IIRC "resident" basically means it doesn't get evicted, and I *think* the only reason I care about eviction is I lose the custom DataVersion. But let's assume I do have a reason to care, or someone else does. | Nodes being marked as resident are also important to increase accuracy of eviction configurations. E.g., maxNodes settings can then only consider nodes that are supposed to have data in them and not structural ones. "bstansberry(a)jboss.com" wrote : | Perhaps the DataVersionProvider concept discussed above should be expanded to handle all such "NodeMetaData": | I think the DataVersionProvider concept should not be developed if DataVersions themselves are a deprecated concept. Metadata is a different story though - there is a JIRA about exposing node metadata as a single object that can be persisted, shipped around - which would include stuff like whether nodes are resident, whether data and child maps are ordered (potentially - this is in discussion), and some transient information like node validity, whether data and/or children are loaded, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168404#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...