From oak-issues-return-61858-archive-asf-public=cust-asf.ponee.io@jackrabbit.apache.org Fri May 4 16:21:05 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 89A17180675 for ; Fri, 4 May 2018 16:21:04 +0200 (CEST) Received: (qmail 62311 invoked by uid 500); 4 May 2018 14:21:03 -0000 Mailing-List: contact oak-issues-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: oak-dev@jackrabbit.apache.org Delivered-To: mailing list oak-issues@jackrabbit.apache.org Received: (qmail 62300 invoked by uid 99); 4 May 2018 14:21:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 May 2018 14:21:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 24C30C136C for ; Fri, 4 May 2018 14:21:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -110.301 X-Spam-Level: X-Spam-Status: No, score=-110.301 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 3DAV0A2l-dBE for ; Fri, 4 May 2018 14:21:02 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id A31D75F4AA for ; Fri, 4 May 2018 14:21:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id D886FE12C8 for ; Fri, 4 May 2018 14:21:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 361A7212A0 for ; Fri, 4 May 2018 14:21:00 +0000 (UTC) Date: Fri, 4 May 2018 14:21:00 +0000 (UTC) From: "Julian Reschke (JIRA)" To: oak-issues@jackrabbit.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (OAK-6421) Phase out JCR Locking support MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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)