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 Tue, 12 Apr 2005 14:31:16 GMT
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.

> 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:

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.

Mime
View raw message