Hi, >> - No change merging. Instead, use MVCC (when reading) and 'node level >> write locking'. As far as I know this is like most MVCC databases >> work. Actually we could use 'property level write locking'. > > right, but that has the major drawback that we cannot write transient > modifications directly into the backend. unless we limit long running > transient-scoped changes with a timer. otherwise a transient > modification could easily hold up other sessions. besides, how would > you support node level write locks in a clustered environment?
> transient modification could easily hold up other sessions Only if both want to write to the same node. I believe this is acceptable within the micro-kernel. > how would you support node level write locks in a clustered environment? > I think there is no way around some change merging. Yes, but it's not necessarily the task of the micro-kernel to merge changes. I suggest that the micro-kernel throws an exception in this case (or asks the "callback mechanism" what to do), and the cluster synchronization mechanism (or whatever is responsible; maybe it's the application, maybe Jackrabbit) merges the changes then. Or re-runs the operation. > I would try to design something that works along the lines of a SCM system. > before > you commit, do an update and merge external changes into your > modification, then commit. I think for most of the conflict scenarios > there are sensible resolutions that will work well in practice. This doesn't work for some cases, for example for reservation systems. I don't think we need to solve "long running transactions" (that run for hours). Those should be split into smaller transactions. Most transactions are very small. Some are quite big (large imports, large deletes). We do need to support those without running out of memory, but I don't think we need to support automatic merging of concurrent writes (at least not within the micro-kernel). Regards, Thomas
