From dev-return-35269-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Fri Jun 8 15:11:04 2012 Return-Path: X-Original-To: apmail-jackrabbit-dev-archive@www.apache.org Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 24A95CF2E for ; Fri, 8 Jun 2012 15:11:04 +0000 (UTC) Received: (qmail 66876 invoked by uid 500); 8 Jun 2012 15:11:04 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 66677 invoked by uid 500); 8 Jun 2012 15:11:03 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 66668 invoked by uid 99); 8 Jun 2012 15:11:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jun 2012 15:11:03 +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 b.vanderschans@1hippo.com designates 64.18.2.217 as permitted sender) Received: from [64.18.2.217] (HELO exprod7og115.obsmtp.com) (64.18.2.217) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 08 Jun 2012 15:10:57 +0000 Received: from mail-qa0-f44.google.com ([209.85.216.44]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT9IV3TckwzI+jKkKOsrwm2Tdk1DLz7RW@postini.com; Fri, 08 Jun 2012 08:10:34 PDT Received: by qadz3 with SMTP id z3so878995qad.17 for ; Fri, 08 Jun 2012 08:10:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=3yt4YhKCFi1IKGkRwV5+j/akN3liyTGZpNjF08YRmp0=; b=SH7JONBEb3zJe0O12eT4utcUBBsX+jWulmQ0Vf3cslHNAYJf/WqZ1P9Z2eJAdK/sj1 ZOn17mVfGyf6xx2UYya5Gl6ohrgjEK6eNfP4qB2CPyFz4PrGuOxG/rDcAWz6sHiict5p hQ8i9t2H+yAN9m8MS0mK1Q3wDuJWCvWH2HNMOu+BXzw2U5fo5vRv8D/9Jnk9XMNTljQX h6Y+HRFWtkieDefapjfHpWb/c2FB1TsDBgjdhV9pam8LfB83KJzZjWeI248QfPawODQt nVoypSaZRyoW4CbxGe0DJs2yAUllM/5BJOF8hfPvV/4JVAaOkXFtscKZpRPBdnFiz1xc U6LA== Received: by 10.229.135.198 with SMTP id o6mr1905768qct.98.1339168220753; Fri, 08 Jun 2012 08:10:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.224.201 with HTTP; Fri, 8 Jun 2012 08:10:00 -0700 (PDT) In-Reply-To: References: From: Bart van der Schans Date: Fri, 8 Jun 2012 17:10:00 +0200 Message-ID: Subject: Re: Mongodb bundle persistence manager To: dev@jackrabbit.apache.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl+TNbS93YM5516G2pOJP+2qLzOKzDMbZwqZhoU80GPTLv6n+KT0AJz3ODu9Nam1PBWnwa0 X-Virus-Checked: Checked by ClamAV on apache.org On Fri, Jun 8, 2012 at 2:59 PM, Jukka Zitting wrote: > Hi, > > On Thu, Jun 7, 2012 at 11:45 PM, Hui Lin wrote: >> anybody get a change to test the code? it would be something nice to have in >> additional to the persistence managers out there already. > > Can you test the code against plain Jackrabbit instead of CRX/CQ? > > Also, it would be easier for us to help if you had a simple test case > that illustrates the problem. Having the MongoDB PM code you included > earlier and the test case as a patch that I can apply against > Jackrabbit trunk would be ideal. > > Note that there's been other efforts to implement the Jackrabbit PM > interface based on NoSQL databases, but such efforts commonly > encounter the issue that Jackrabbit 2.x expects the operation of > saving transient changes to be atomic. Do you have a way to ensure > that with MongoDB? Afaik the two things you have to take care of with clustering of JR 2.x on an eventual consistency store are: - only one cluster node at a time can write to the repository journal and update the global revision id (aka all writes are serialized/ordered) - when a cluster node reads the global revision id, it must be able to read all journal entries up to that id (aka one happens before the other) So with MongoDB you might need an external locking mechanism to achieve this, but I'm no MongoDB expert (yet..) Regards, Bart