jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: Transaction and locks
Date Thu, 14 Apr 2005 14:35:03 GMT
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...


View raw message