Hi David
David Nuescheler wrote:
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
Ok, take two transactional resources, if you want, two different repositories (maybe that's more likely).
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.
When you commit the transaction, the transaction manager will call commit on both sA and sB. If sA fails to commit (and it will not fail until sA and sB are in prepared state because prepare() is a no-op at the moment) it is impossible to rollback the transaction as sA AND sB are both instructed to commit by the transaction manager.
I hope you see my point now. For me, ACIDity seems very highly endangered.
Regards,
Felix
the current jackrabbit implementation is slightly different, however ACID should never be endangered.
maybe you can clarify your question for me...
regards, david
