Enforcing JCR Locks | Community
Skip to main content
J
jdawyers
March 14, 2018
Solved

Enforcing JCR Locks

  • March 14, 2018
  • 2 replies
  • 1338 views

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.

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by joerghoh

    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

    2 replies

    joerghoh
    Adobe Employee
    joerghohAdobe EmployeeAccepted solution
    Adobe Employee
    March 14, 2018

    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

      J
      jdawyersAuthor
      March 14, 2018

      Thank you. This is extremely helpful!

      Terms & ConditionsAccessibility statement

      Loading footer...