jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Deployment question: is Jackrabbit process-safe? [SEC=UNCLASSIFIED]
Date Tue, 04 Sep 2012 07:18:38 GMT
Each JR process locks the repository with a lock file in the local
repository file system, but to make more than one JR process work on
the same repository you must a) use a shared database (eg PorstgreSQL,
MySQL, Oracle etc) and b) you must configure each JR process with a
Cluster Node setting[1] in the repository.xml.

Once you have done this, events generated on one node will propagate
to other nodes via the shared database and ensure the local copies of
the Lucene index are at the same revision. It performs this via a
Jornal table.

One thing to note however. Writing blocks of events to the journal
table will exclusively lock the end of the table meaning that only on
JR process can can have an inprocess transaction active at any one
time. This is OK for the use cases that JR2 and earlier was designed
for, ie 90% read, but can be problematic if you want many of your JR
nodes to write concurrently.


1 http://wiki.apache.org/jackrabbit/Clustering

On 4 September 2012 10:10,  <Ross.Dyson@ipaustralia.gov.au> wrote:
> the first jackrabbit to start up the repository locks the repository by
> creating a lock file.
> Ross
> From:        "Esmond Pitt" <esmond.pitt@bigpond.com>
> To:        <users@jackrabbit.apache.org>
> Date:        04/09/2012 10:04 AM
> Subject:        Deployment question: is Jackrabbit process-safe?
> ________________________________
> I have a clustered web-app that uses Jackrabbit. I presently have Jackrabbit
> in yet another Tomcat and am using RMI to communicate with it. However it
> occurs to me that I could just include the JackRabbit API jars in the webapp
> and call it directly, *provided* multiple copies of the Jackrabbit API will
> co-operate correctly on the database. Is this the case?
> --
> This message contains privileged and confidential information only
> for use by the intended recipient.  If you are not the intended
> recipient of this message, you must not disseminate, copy or use
> it in any manner.  If you have received this message in error,
> please advise the sender by reply e-mail.  Please ensure all
> e-mail attachments are scanned for viruses prior to opening or
> using.

View raw message