jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-2149) Locks are not enforced
Date Wed, 19 Aug 2015 11:09:46 GMT

    [ https://issues.apache.org/jira/browse/OAK-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14702859#comment-14702859

Julian Reschke commented on OAK-2149:

There are multiple ways to look at this.

a) We shouldn't give the impression that we support proper JCR locking when we don't, thus
adding checks is not a good idea.

b) Even if we can't always enforce locks, we should try to enforce them when we can.

I started with a), but now I'm leaning towards b): not doing any checking might cause people
to *rely* on this behavior, which might make it even harder to implement proper locking later

> Locks are not enforced
> ----------------------
>                 Key: OAK-2149
>                 URL: https://issues.apache.org/jira/browse/OAK-2149
>             Project: Jackrabbit Oak
>          Issue Type: Sub-task
>          Components: core, jcr
>    Affects Versions: 1.0.6
>            Reporter: Damien Obrist
>         Attachments: 0001-OAK-2149-Locks-are-not-enforced.patch
> Locks are not enforced and do not prevent nodes from being modified by non-lock-owning
> Consider following code excerpt:
> {code:java}
> Repository repo = ...
> String path = "/some/node";
> Session session1 = repo.login(new SimpleCredentials("A", "password".toCharArray()));
> session1.getNode(path).addMixin("mix:lockable");
> session1.save();
> LockManager lockManager = session1.getWorkspace().getLockManager();
> lockManager.lock(path, true, false, Long.MAX_VALUE, null);
> Session session2 = repo.login(new SimpleCredentials("B", "password".toCharArray()));
> session2.getNode(path).setProperty("foo", "bar");
> session2.save();
> {code}
> User {{A}} puts a lock on {{/some/node}}. User {{B}} is still able to set a property
on that node after it has been locked. Instead, this should throw a {{LockException}}.

This message was sent by Atlassian JIRA

View raw message