jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Röthenbacher <felix.roethenbac...@wyona.com>
Subject Re: Transaction and locks
Date Thu, 14 Apr 2005 15:29:35 GMT
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
> 

Mime
View raw message