Already in edit mode

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Already in edit mode

Robert Haycock
Hi,

We occasionally get an exception with message "Already in edit mode". After some debugging it looks like it's due to the un-thread safe nature of the expired lock tidy up.

We get this log message...
2017-06-15 15:47:06,389  WARN [jackrabbit-pool-4] [] (LockManagerImpl.java:197) - Unable to expire the lock. NodeId 0203f4b3-c9b5-44c9-a047-2ee35cdeaba0
javax.jcr.RepositoryException: Unable to remove lock properties.
     at org.apache.jackrabbit.core.lock.LockManagerImpl.removeLockProperties(LockManagerImpl.java:986)
     at org.apache.jackrabbit.core.lock.LockManagerImpl.unlock(LockManagerImpl.java:596)
     at org.apache.jackrabbit.core.lock.LockManagerImpl$TimeoutHandlerVisitor.elementVisited(LockManagerImpl.java:195)
Followed by another message, in a different thread, either "Already in edit mode" or "Not in edit mode".
In LockManagerImpl.TimeoutHandlerVisitor, the elementVisited() method has this comment...

     // FIXME: This session access is not thread-safe!

I've just checked version  2.14.1 and the comment is still there.

Indeed, this appears to be true and causing us random grief. Is there a fix/workaround other than not allowing locks to expire?

Any plans to fix?

Thanks,
Rob.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Already in edit mode

Robert Haycock
Hi,

We occasionally get an exception with message "Already in edit mode". After some debugging it looks like it's due to the un-thread safe nature of the expired lock tidy up.

We get this log message...
2017-06-15 15:47:06,389  WARN [jackrabbit-pool-4] [] (LockManagerImpl.java:197) - Unable to expire the lock. NodeId 0203f4b3-c9b5-44c9-a047-2ee35cdeaba0
javax.jcr.RepositoryException: Unable to remove lock properties.
     at org.apache.jackrabbit.core.lock.LockManagerImpl.removeLockProperties(LockManagerImpl.java:986)
     at org.apache.jackrabbit.core.lock.LockManagerImpl.unlock(LockManagerImpl.java:596)
     at org.apache.jackrabbit.core.lock.LockManagerImpl$TimeoutHandlerVisitor.elementVisited(LockManagerImpl.java:195)

Followed by another message, in a different thread, either "Already in edit mode" or "Not in edit mode".

In LockManagerImpl.TimeoutHandlerVisitor, the elementVisited() method has this comment...

     // FIXME: This session access is not thread-safe!

I've just checked version  2.14.1 and the comment is still there.

Indeed, this appears to be true and causing us random grief. Is there a fix/workaround other than not allowing locks to expire?

Any plans to fix?

Thanks,
Rob.
Loading...