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.
Regards
Felix
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
transactions.
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 [EMAIL PROTECTED]
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
