jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bart van der Schans <b.vandersch...@onehippo.com>
Subject Re: Mongodb bundle persistence manager
Date Fri, 08 Jun 2012 15:10:00 GMT
On Fri, Jun 8, 2012 at 2:59 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On Thu, Jun 7, 2012 at 11:45 PM, Hui Lin <hlin@consumer.org> 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

Mime
View raw message