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 2C6DDEE4D for ; Wed, 27 Feb 2013 15:43:12 +0000 (UTC) Received: (qmail 20971 invoked by uid 500); 27 Feb 2013 15:43:12 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 20923 invoked by uid 500); 27 Feb 2013 15:43:12 -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 20915 invoked by uid 99); 27 Feb 2013 15:43:12 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Feb 2013 15:43:12 +0000 Received: from localhost (HELO mail-oa0-f44.google.com) (127.0.0.1) (smtp-auth username cziegeler, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Feb 2013 15:43:11 +0000 Received: by mail-oa0-f44.google.com with SMTP id h1so1436491oag.3 for ; Wed, 27 Feb 2013 07:43:10 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.98.79 with SMTP id eg15mr2484362obb.70.1361979790739; Wed, 27 Feb 2013 07:43:10 -0800 (PST) Received: by 10.60.50.2 with HTTP; Wed, 27 Feb 2013 07:43:10 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Feb 2013 16:43:10 +0100 Message-ID: Subject: Re: Behaviour of Move Operations From: Carsten Ziegeler To: oak-dev@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 Thanks Jukka, is the configuration of the journal a repository wide configuration or is it configurable for sub trees? Regards Carsten 2013/2/27 Jukka Zitting : > Hi, > > On Wed, Feb 27, 2013 at 5:09 PM, Carsten Ziegeler wrote: >> How will this be handled with Oak? Could it happen that due to this >> happening concurrently that the node ends up twice in the repository >> (at /1/node and /2/node in my example)? > > The behavior depends on the underlying MicroKernel implementation. > > With the new SegmentMK I've been working on, you can control the behavior: > > * If both cluster nodes use the same (root) journal, then only one of > them succeeds and the other one will fail with an exception. The > behavior is more or less the same as with current Jackrabbit. > > * If the cluster nodes use different journals (with background > merging), then one of the moves will succeed and depending on timing > the other one either fails or ends up producing a duplicate copy of > the tree. > > The latter option is designed to boost write concurrency in scenarios > where it's OK for some operations to get lost or produce somewhat > inconsistent results (high-volume commenting or logging systems, > etc.). Operations for which such behavior is not desirable should use > the first option. > > BR, > > Jukka Zitting -- Carsten Ziegeler cziegeler@apache.org