angela created OAK-1962:
---------------------------
Summary: 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
Fix For: 1.1
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.2#6252)
