Torsten Curdt wrote: > I am wondering how "concurrent" writes are handled with > jcr/jackrabbit. While the spec (4.1.3.2 Transient Storage in the > Session) does answer some of the questions I was wondering about some > of the details. > > Let's say I have two people A and B editing a node from a JCR > repository. Both hold a reference to the node concurrently in > different sessions. Both modify some properties. Now A saves his > session, then B saves his session. IIUC the repository would now show > the state of B's session as B was essentially last. Assuming the node > has mixin mix:versionable I would expect to revisions like > > 1 original > 2 from A > 3 from B > > Are these assumptions correct?
depends on what exactly you mean with 'some properties'. if the sets of modified properties from A and B overlap you get an InvalidItemStateException. See: http://www.day.com/specs/jcr/1.0/7.1.1.4_Invalid_States.html versioning is a different story. if you want to be sure that a modify-item/version-item sequence works without an InvalidItemStateException then you need to lock the item before you modify it and finally unlock it after you versioned it. > Would there be any sign/notification (exception/return code) for B > that the node he wants to write to was changed by A? yep, the above mentioned exception. regards marcel
