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-6421) Phase out JCR Locking support
Date Fri, 04 May 2018 14:21:00 GMT

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

Julian Reschke commented on OAK-6421:

Quick summary:

With the changes attached to OAK-7471, all tests pass. I found that the TCK mostly was handling
this properly, and the test coverage for repositories without locking was already there.

With respect to the actual changes in oak-jcr, we need to discuss:

- Can we make this more elegant somehow? Just tuning the LockManager wasn't sufficient in
the end, because {{getLockManager}} already needs to throw...

- What to do with mix:lockable in the node type registry? We could hide it, but then it might
be sufficient not to allow adding it. That said, the current checks wouldn't handle types
extending from a node type that includes mix:lockable. (These checks would need to check the
effective node type, as compared to just the name)

- What to do with migrations scenarios, where existing content already contains lockable nodes...

> Phase out JCR Locking support
> -----------------------------
>                 Key: OAK-6421
>                 URL: https://issues.apache.org/jira/browse/OAK-6421
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: jcr
>            Reporter: Marcel Reutegger
>            Priority: Major
>             Fix For: 1.10
> Oak currently has a lot of gaps in its JCR Locking implementation (see OAK-1962), which
basically makes it non-compliant with the JCR specification.
> I propose we phase out the support for JCR Locking because a proper implementation would
be rather complex with a runtime behaviour that is very different in a standalone deployment
compared to a cluster. In the standalone case a lock could be acquired very quickly, while
in the distributed case, the operations would be multiple orders of magnitude slower, depending
on how cluster nodes are geographically distributed.
> Applications that rely on strict lock semantics should use other mechanisms, built explicitly
for this purpose. E.g. Apache Zookeeper.
> To ease upgrade and migration to a different lock mechanism, the proposal is to introduce
a flag or configuration that controls the level of support for JCR Locking:
> - DISABLED: the implementation does not support JCR Locking at all. Methods will throw
UnsupportedRepositoryOperationException when defined by the JCR specification. 
> - DEPRECATED: the implementation behaves as right now, but logs a warn or error message
that JCR Locking does not work as specified and will be removed in a future version of Oak.
> In a later release (e.g. 1.10) the current JCR Locking implementation would be removed
entirely and unconditionally throw an exception.

This message was sent by Atlassian JIRA

View raw message