[
https://issues.apache.org/jira/browse/OAK-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946295#comment-13946295
]
angela commented on OAK-1329:
-----------------------------
well... then this code relies on a particular behavior of the implementation
and not on the specification. the specification is pretty unambigous:
- Lock#geetLockToken : May return the lock token for this lock. If this lock is
open-scoped and the current session either holds the lock token for this lock,
or the repository chooses to expose the lock token to the current session, then
this method will return that lock token.
- LockManager#holdsLock reveals if the editing session is the lock holder
I would return the lock token of the editing session corresponds to the lock
owner and no other session is lock holder (i.e. token got lost).
Maybe that then needs some adjustment in existing code that makes wrong
expectations about Lock#getLockToken.
> Relaxed JCR locking behavior
> ----------------------------
>
> Key: OAK-1329
> URL: https://issues.apache.org/jira/browse/OAK-1329
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
> Reporter: Marcel Reutegger
> Assignee: Jukka Zitting
> Priority: Blocker
> Fix For: 0.20
>
>
> Open scoped locks in JCR can be quite troublesome to use in practice. Mainly
> because of the requirement to remember the token generated by a lock
> operation. This token must be added again to the session when a unlock is
> called. The problematic part is where to store the token und what happens
> when the token is lost. In practice it is usually more desireable to allow
> any session autenticated for a given user to unlock the nodes for which
> he/she is the lock owner (identified by the jcr:lockOwner property).
> I suggest we make this a deployment option.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
