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 2BC2B97D8 for ; Tue, 3 Apr 2012 10:27:23 +0000 (UTC) Received: (qmail 85335 invoked by uid 500); 3 Apr 2012 10:27:23 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 85302 invoked by uid 500); 3 Apr 2012 10:27:23 -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 85294 invoked by uid 99); 3 Apr 2012 10:27:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Apr 2012 10:27:23 +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 (athena.apache.org: domain of mueller@adobe.com designates 64.18.1.181 as permitted sender) Received: from [64.18.1.181] (HELO exprod6og101.obsmtp.com) (64.18.1.181) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Apr 2012 10:27:14 +0000 Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKT3rQbKTjNwnnVosG0NJYc2xl9GdxosJi@postini.com; Tue, 03 Apr 2012 03:26:52 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q33AOkJ0019603 for ; Tue, 3 Apr 2012 03:24:47 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q33AQn2b028511 for ; Tue, 3 Apr 2012 03:26:50 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 3 Apr 2012 03:26:49 -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:26:44 +0100 From: Thomas Mueller To: "oak-dev@jackrabbit.apache.org" Date: Tue, 3 Apr 2012 11:26:43 +0100 Subject: Re: oak-api and move operations Thread-Topic: oak-api and move operations Thread-Index: Ac0RhEQY+RNPg11PSYmKpTm/ld+9UQ== Message-ID: In-Reply-To: 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 X-Virus-Checked: Checked by ClamAV on apache.org Hi, >This is exactly the same operation as two MicroKernel cluster nodes >will need to perform when syncing concurrent commits. Yes, only that synching concurrent commits can be implemented on a higher layer (above indexing). So it's not quite the same. >AFAICT it should be possible to do this without knowledge of higher >level semantics=20 I personally don't think that's the case. >as long as possible merge conflicts are recorded and >left to higher level components to resolve as they see fit. That would complicate things quite a bit. >this is something that we in any case need to do for >clustering, so I don't see the explicit merge() method adding any >extra work for us. I would like to wait until we have a clearer picture how clustering is implemented. >>Also, some MicroKernel implementations (for example a MongoDB >> MicroKernel implementation) might not be able to support branching >> and merging. > >They need to if they're going to support concurrent writes on more >than one cluster node. It sounds like you already have some particular way to implement a clustered MongoDB MicroKernel in mind. If yes, could you share your ideas? Regards, Thomas