[
https://issues.apache.org/jira/browse/JCR-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178798#comment-13178798
]
angela commented on JCR-2859:
-----------------------------
> by changing the default timeout from "Infinity" to something reasonable
yes. that definitely makes sense... maybe we could even make the default
timeout part of the workspace
configuration as the preferred timeout may vary between different types of
applications.
in any case we should clarify that as a general rule it is preferable to
specify a reasonable timeout
suited for the situation when creating a new lock... LockManager#lock always
takes a timeout hint, while
Node.lock (which doesn't support it) has been deprecated as of JSR 283.
> Make open scoped locks recoverable
> ----------------------------------
>
> Key: JCR-2859
> URL: https://issues.apache.org/jira/browse/JCR-2859
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: locks
> Affects Versions: 2.2
> Reporter: Carsten Ziegeler
> Assignee: Julian Reschke
> Attachments: JCR-2859.diff, JCR-2859.patch, OpenScopeLockTest.java
>
>
> The lock tokens for open scoped locks are currently tied to the session which
> created the lock. If the session dies (for whatever reason) there is no way
> to recover the lock and unlock the node.
> There is a theoretical way of adding the lock token to another session, but
> in most cases the lock token is not available.
> Fortunately, the spec allows to relax this behaviour and I think it would
> make sense to allow all sessions from the same user to unlock the node - this
> is still in compliance with the spec but would make unlocked locked nodes
> possible in a programmatic way.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
