jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Marth (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OAK-1962) Fix and Improve Locking
Date Tue, 10 Mar 2015 16:16:38 GMT

     [ https://issues.apache.org/jira/browse/OAK-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Michael Marth updated OAK-1962:
    Fix Version/s:     (was: 1.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
>             Fix For: 1.4
> 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
> 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

View raw message