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:[EMAIL PROTECTED] Gesendet: Mittwoch, 06. August 2008 10:43 An: [email protected] Betreff: Re: lock problem in xa transaction Hi, On Wed, Aug 6, 2008 at 9:39 AM, KÖLL Claus <[EMAIL PROTECTED]> 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
