[
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
(v7.6.3#76005)
