hi felix, > [1] begin > [2] lock nA in sA > [3] lock nB in sB > [4] sA.save > [5] sB.save > [6] commit > [1] start of transaction, enlist the two resources > [2] Is a LockException thrown if node is locked already? > As stated in the spec, the lock is not visible in > other sessions, right? > [4,5] save node changes for committing > [6] commit changes: changes are made visible to > other sessions. What happens, if another > session sC successfully locked node nA between the > execution of [4] and [6]? As Dominique mentioned, > the prepare() method is currently a no-op and > there is no possibility to prevent that node > nB is locked (returns prepared ok) and node > nA is not (LockException). It seems that > the ACID property of this transaction is broken.
not only do i find this example highly unlikely (two sessions against the same repository, within one transaction) and pointless (save() has no role in it at all, since lock is auto saved) but to me it also confuses the point that you seem to want go after. let me try to rephrase your example, how i understand the above questions: (which btw has nothing todo with xa but is just a general transaction question) [1] begin sA [2] lock sA, nX [3] begin sC [4] lock sC, nX [5] commit sC [6] commit sA what happens according to the spec is that in step [6] the commit would fail and the transaction will be rolled back. the current jackrabbit implementation is slightly different, however ACID should never be endangered. maybe you can clarify your question for me... regards, david
