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.