Enforcing JCR Locks

[jdawyers]

When placing a lock on a component node, I have used mix:lockable and mix:simpleVersionable. From the Content Explorer I then placed a deep lock on a component node in the hopes that no one else would be able to edit it until I was done. However, it seems that the locks are not being enforced.

Has anyone come across this? Seems like it would be a permissions issue, but I don't see a way around giving someone modify permissions since they do need to be able to edit components, just not when someone else is.

[Jörg_Hoh · Accepted solution]

A quote from Jackrabbit Oak – Backward compatibility

Oak does not support the strict locking semantics of Jackrabbit 2.x. Instead a “fuzzy locking” approach is used with lock information stored as normal content changes. If a mix:lockable node is marked as holding a lock, then the code treats it as locked, regardless of what other concurrent sessions that might see different versions of the node see or do. Similarly a lock token is simply the path of the locked node.

This fuzzy locking should not be used or relied as a tool for synchronizing the actions of two clients that are expected to access the repository within a few seconds of each other. Instead this feature is mostly useful as a higher level tool, for example a human author could use a lock to mark a document as locked for a few hours or days during which other users will not be able to modify the document.

--

Jörg

[jdawyers]

Thank you. This is extremely helpful!