Uploaded image for project: 'Jackrabbit Oak'
  1. Jackrabbit Oak
  2. OAK-1962

Fix and Improve Locking

Attach filesAttach ScreenshotAdd voteVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0
    • Fix Version/s: None
    • Component/s: core, jcr
    • Labels:

      Description

      as discussed during our biweekly planning session, we are having the following locking related use case in our product:

      a page (which is an aggregation of nodes and properties) must be freezed (prevented from being edited/modified/deleted) during the period of a dedicated review (which in our case is triggered by a workflow) before the page then is either published or reopened for further changes.

      for this feature locking would be a perfect match but with the current implementation in oak it's not possible to remove the lock token from a given session and make sure it's no longer recognizes as lock owner; in particular with the simple-locking feature which we introduced in order to cope with the situation that in our product sessions are living just for the time of a single request.

      is was therefore thinking about ways to address this, keeping the simple-locking requirement in mind while at the same time improving compliance with the JCR specification. my suggestion as follows:

      • use a dedicated hidden and write protected location the repository to store the lock information independent of the protected properties defined by mix:lockable which are just for information purpose (that would be the replacement for the lock-related file we had in jackrabbit 2.x)
      • format: simple lookup consisting of userId + associated lock tokens
      • in case of simple locking LockManager#getLockTokens would make use of that map even if the lock tokens have NOT been explicitly added to the Session either upon LockManager#lock or LockManager#addLockToken
      • in the default (non-simple case) LockManager#getLockTokens would work as specified and the lookup would only be used for maintaining and enforcing the lock related information)
      • LockManager#removeLockToken removes the token from the lookup thus effectively revoking the lock ownership from the given Session and thus preventing it from performing further editing... even in the simple-locking case
      • LockManager#addLockToken results in a modification of the lookup table as well depending on the API contract (i.e. verifying if the lock token would be shared... i don't remember exactly if that's accepted by the specification)
      • LockManager#isLockOwner no longer needs to perform a cheap hack comparing the jcr:lockOwner property with the sessions userId but could really enforce ownership based on the internal lock information stored in the repository in which case getLockTokens would really reflect the ownership for open-scoped locks; furthermore the 'jcr:lockOwner' information could be to what is specified by the API consumer upon LockManager#lock as it is no longer used for enforcing the locks.

      in addition:

      • we could generated proper lock tokens instead of just using the node id
        and again keep those in a hidden (or otherwise protected) location in the system.

        Attachments

        Issue Links

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              angela Angela Schreiber

              Dates

              • Created:
                Updated:

                Issue deployment