From oak-dev-return-534-apmail-jackrabbit-oak-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Tue Apr 3 10:21:36 2012 Return-Path: X-Original-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B9A4B9276 for ; Tue, 3 Apr 2012 10:21:36 +0000 (UTC) Received: (qmail 71143 invoked by uid 500); 3 Apr 2012 10:21:36 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 71108 invoked by uid 500); 3 Apr 2012 10:21:36 -0000 Mailing-List: contact oak-dev-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-dev@jackrabbit.apache.org Received: (qmail 71100 invoked by uid 99); 3 Apr 2012 10:21:36 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Apr 2012 10:21:36 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mueller@adobe.com designates 64.18.1.35 as permitted sender) Received: from [64.18.1.35] (HELO exprod6og115.obsmtp.com) (64.18.1.35) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Apr 2012 10:21:27 +0000 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKT3rPEbZeoQE+pfeYaY9dG5KSujVOFxYh@postini.com; Tue, 03 Apr 2012 03:21:06 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q33AL4v7019944 for ; Tue, 3 Apr 2012 03:21:04 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q33AL42a027703 for ; Tue, 3 Apr 2012 03:21:04 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 3 Apr 2012 03:21:03 -0700 Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Tue, 3 Apr 2012 11:21:00 +0100 From: Thomas Mueller To: "oak-dev@jackrabbit.apache.org" Date: Tue, 3 Apr 2012 11:20:58 +0100 Subject: Re: oak-api and move operations Thread-Topic: oak-api and move operations Thread-Index: Ac0Rg3bMTOBPyFuNT3Cc4caXtz7VHg== Message-ID: In-Reply-To: <4F7ACCC1.1090401@apache.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi, >I think there is some misunderstanding here. There is not more merging >to be done by the Microkernel as it already does. Currently transient >changes are kept in memory and passed to the Microkernel in a single >commit call passing along a possible prohibitively large json diff. With >the "private branch" approach, the transient changes are simple written >ahead into a private branch and only on merge are these applied to the >main branch. Think of it like a write ahead of the json diff to the >Microkernel (although the implementation might differ). Currently, commit calls can be easily synchronized in the MicroKernel implementation. If you want to achieve a similar isolation with branch() and merge(), then a branch() would block other commits (and branch calls) until the merge() call. That would work I guess. One remaining problem is then the ability to "undo" (rollback) a branch. I guess there should be a method for that ("revert"). Another remaining problem is that each MicroKernel implementation would need to support transactions that span multiple calls (similar to 2-phase commits or transaction savepoints). Regards, Thomas