Hi, This thread is confusing two different things: the UUID accessible as the jcr:uuid property of a JCR node, and the internal reference used by the underlying storage implementation to locate a specific node state. In Jackrabbit 2.x these are the same, but in jr3/oak this is no longer the case since the MVCC model implies that the internal storage references change at each content change.
IIUC Thomas' original post was about the latter case, i.e. the internal storage references, *not* jcr:uuid properties. The tree interface we've been drafting in the other thread explicitly hides the underlying storage identifiers, which should help isolate this design decision from higher levels of code. Rather than discuss this issue in the abstract, I suggest that we define a set of relevant performance benchmarks, and use them for evaluating potential alternatives. BR, Jukka Zitting
