Hi, In that case, if you want to prevent B's writing, A has to lock the node before writing. I don't think B could receive any notification of changes by A.
And without lock mechanism, your assumptions are correct. won -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Torsten Curdt Sent: Monday, January 05, 2009 4:08 AM To: [email protected] Subject: concurrent writes 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? Would there be any sign/notification (exception/return code) for B that the node he wants to write to was changed by A? cheers -- Torsten
