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: Add more options to make Jackrabbit more failsafe and/or scale-out
Date Wed, 11 May 2011 11:14:37 GMT
On Wed, May 11, 2011 at 12:54 PM, Christian Stocker
<christian.stocker@liip.ch> wrote:
> Hi
> Just one thing to avoid missunderstandings.
> On 11.05.11 12:01, Bart van der Schans wrote:
>> Hi Christian,
>> Does anybody have some pointer why it's trying to write? It seem to
>> shutdown just fine anyway.. It doesn't make much sense to me to create
>> a ReadOnlyDatabaseFileSystem just to avoid this shutdown issue.
>> I think the solution I created is a bit more narrow as it only aims to
>> allow to run JR on a database slave node independently. I think
>> Christian's idea can be expanded to separate all write database
>> operations from read operations in JR, which would allow for scaling
>> out in heavy read dependent environments  with multiple db slaves
>> while keeping a single db master for handling all writes.
> My patch only seperates the read/writes for the cluster journal
> operations. It doesn't seperate the "common" read/write request handled
> by the PM. This of course only works, if your Jackrabbit instances using
> the slaves only do reads and no PM-writes at all. You should handle the
> seperation in your application (read from the read-only Jackrabbit, but
> write to the write-enabled Jackrabbits), the same as you would do, you
> if you would use a traditional master/slave MySQL Setup (with no
> Jackrabbit or other CR at all)

That's why I said your patch/idea could be "expanded" ;-) If the db
operations where read/write separated, you wouldn't have to worry in
your application about "write-enabled" JRs. Then JR would take care of
doing the writes in the master database and the reads from the slave


View raw message