[
https://issues.apache.org/jira/browse/OAK-6421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-6421:
---------------------------------
Fix Version/s: (was: 1.38.0)
1.40.0
> 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.40.0
>
>
> 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
(v8.3.4#803005)
