[
https://issues.apache.org/jira/browse/OAK-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Saar updated OAK-1962:
--------------------------------
Fix Version/s: (was: 1.6)
1.8
> Fix and Improve Locking
> -----------------------
>
> Key: OAK-1962
> URL: https://issues.apache.org/jira/browse/OAK-1962
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
> Affects Versions: 1.0
> Reporter: angela
> Labels: technical_debt
> Fix For: 1.8
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
