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 13:14:16 GMT
David Nuescheler wrote:
> hi felix,
>>>>I wonder what happens with locks aquired in the course of
>>>>executing a transaction when the transaction is commited
>>>>or rolled back. Is it the responsibility of the application
>>>>to release the locks or will the repository take care of this?
>>>how about chapter "8.5.10 Locks and Transactions" in the spec ;)
>>If I understand "8.5.10 Locks and Transactions" right, locking
>>can never be part of a global transaction where prior successful
>>locking is required for a successful commit.
> if you say "prior" do you mean before the transaction?
> of course locking can easily be part of a global transaction.

I try to lock two nodes in different transactional resources
spanned by a global transaction before doing some work.
See scenario below ...

>>A scenario where the lock can't be obtained (e.g. timeout) and
>>the whole global transaction should be rolled back would not be
>>possible if the locking is part of a separate transaction.
> that's exactly how it works... 
> as defined in the mentioned chapter
> "In order to use locks properly, locking and unlocking must 
> be done in separate transactions"
> something like this sequence is permissable:

As mentioned above locking and unlocking must be done in
separate transactions according to the spec.

Now my question is what happens in the following scenario:

A global transaction over two transactional resources (say
sessions) sA and sB should be executed:

[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.



> begin
>  lock
>  do A 
>  save
> commit 
> begin
>  do B 
>  save
>  unlock
> commit 
>>Using nested transactions is afaik no alternative because
>>transactional resources are not required to support nested
> of course.
>>What is best practices with global transactions
>>and jackrabbit?
> Global (XA) Transaction behaviour is part of the JSR-170 spec.
> "8.1. Transactions" and for example "8.1.1 Container Managed 
> Transactions: Sample Request Flow"
> i think all this stuff is really prominently documented in the spec.
> can we do something to make it easier for you to find these 
> sections?
> regards,
> david
> .ps: a common mistake is to use locks to achieve ACID which is
> pointless overhead in a transactional environment.

Felix Röthenbacher                  felix.roethenbacher@wyona.com
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com                      http://lenya.apache.org

View raw message