jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From KÖLL Claus <C.KO...@TIROL.GV.AT>
Subject AW: lock problem in xa transaction
Date Wed, 06 Aug 2008 09:22:21 GMT
hi jukka thanks for your comments.

we have jackrabbit configured as a jca adapter so we have transactions at all.
my use case is to add a node and create a non-session scoped lock on it
and i think this is a legitimate usecase ...

but somebody had the idea to test it because in the current XATest.class
is already such a testcase but it will not be invoked ??

i don't know exactly but can it be that Marcel Reutegger is the xa implementor ?

i have some time ago created a issue JCR-1334 where i found some problems with
locking in transactions. there the lock will be bind to the current thread but
in a xa environment you can not bind a lock to a thread because you can not guarantee
that a application server give you for a commit() the same thread as for prepare(). in the
testcases for the current
implementation we should test such things ...

from my point of view we should think about transactions in jackrabbit again
to find solutions for that problems. in JCR-1702 the problem is the mix of sessions


thanks
claus

-----Ursprüngliche Nachricht-----
Von: Jukka Zitting [mailto:jukka.zitting@gmail.com] 
Gesendet: Mittwoch, 06. August 2008 10:43
An: dev@jackrabbit.apache.org
Betreff: Re: lock problem in xa transaction


Hi,

On Wed, Aug 6, 2008 at 9:39 AM, KÖLL Claus <C.KOELL@tirol.gv.at> wrote:
> sorry for my hardheadedness
> but is there nobody out who can give some statement to that problem ?
> i have created a jira issues JCR-1702 for that problem

I'm not sure what the right answer here would be.

Ideally a session inside a transaction should behave as close as
possible to a session outside one, but in this case it doesn't. One
reason for this behaviour is that until the transaction is committed
the created node is only visible within the transaction, so locking it
doesn't really achieve much. I'm not sure how things end up looking
internally in Jackrabbit for such a case, it seems like in JCR-1702
you've already dug deeper than what I can tell from the top of my
head.

More generally the effect of locking within a transaction is a tricky
subject, e.g. should a lock within a transaction affect clients
outside the transaction?

In any case the behaviour you are seeing is confusing. If such locking
is not supported, then already the lock() method should throw an
exception instead of the failure being manifest as an
ItemNotFoundException that causes commit() to fail.

BR,

Jukka Zitting

Mime
View raw message