Hi, I have investigated this problem and I think I have a basic idea what is happening:
The error happens in the global Lockmanager in the class org.apache.jackrabbit.core.lock.LockManagerImpl in the method internalUnlock(NodeImpl node). This LockManager tries to find the node that should be unlocked in a PathMap called lockMap and throws "LockException: Node not locked" if it can't be found. Because we are in a transaction, the actual move operation and with it the refresh of the mentioned PathMap in the global LockManager only happens upon commit. The unlocking however seems to be done within the prepare of the transaction, so this will always happen before the commit and actual move. This means that the LockManager and it's lockMap can't know about the changed path yet and will fail, because the entry in the lockMap still contains the old path. I don't know if this is a bug or if there is something wrong with the way move/unlock is used in the test case and I didn't find a workaround for this problem yet. Would be great if someone has any ideas for this issue. Kind regards, Thomas -- View this message in context: http://jackrabbit.510166.n4.nabble.com/Move-Locks-and-Transactions-tp4662332p4662354.html Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
