[
https://issues.apache.org/jira/browse/OAK-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876530#comment-13876530
]
Julian Reschke commented on OAK-1329:
-------------------------------------
Nope. It may be a problem in Jackrabbit, but not in the spec.
<http://www.day.com/specs/jcr/2.0/17_Locking.html#17.12.4%20Getting%20a%20Lock%20Token>:
17.12.4 Getting a Lock Token
String Lock.getLockToken()
may return the lock token for this lock. If this lock is open-scoped and the
current session holds the lock token for this lock, then this method will
return that lock token. If the lock is open-scoped and the current session does
not hold the lock token, it may return the lock token. Otherwise this method
will return null.
> 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
>
> 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.1.5#6160)
