You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Ryan Hochstetler <ry...@JETISRE.COM> on 2010/06/14 22:54:27 UTC

Clustered Jackrabbit

First the question, then the background:

 

Is it necessary to configure a <Journal> in the repository XML when one
and only one node is accessing a JCR datastore which is typically used
in a clustered configuration?  Is the <Journal> necessary for absolute
datastore coherency once the JCR has been configured in journaled mode,
or is it only used to keep concurrent readers and writers synchronized
with each other?

 

We have a two-node jackrabbit cluster which hosts our application
configuration data.  We use bundle.OraclePersistenceManager with
Jackrabbit hitting a non-jta datasource in JBoss.  It works nicely.  We
have a separate application which serves as a failsafe configuration
editor, in case an administrator manages to corrupt the configuration
and leave JBoss unbootable or crippled.  This separate application does
not have the benefit of the database authentication code in JBoss
(customer requirements specify that we can't put the password in the
repository.xml).  We've worked around the issue with for the
PersistenceManager, but I'd prefer not to have to go through the same
steps for the DatabaseJournal.

 

Will it corrupt the JCR database tables if the journal table is not
updated when running the failsafe configuration editor?  There would be
no other readers or writers at the time.  Once the configuration is
repaired, the failsafe app is shut-down and the JBoss cluster would be
started again.

 

Thanks,

Ryan Hochstetler

Senior Software Engineer

JET Enterprise Team

Raytheon Company


Re: Clustered Jackrabbit

Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Jun 14, 2010 at 22:54, Ryan Hochstetler
<ry...@jetisre.com> wrote:
> First the question, then the background:
>
>
>
> Is it necessary to configure a <Journal> in the repository XML when one
> and only one node is accessing a JCR datastore which is typically used
> in a clustered configuration?

I don't understand: the purpose of a cluster is that multiple nodes
share the same repository. And if you have a cluster, you need the
journal. The journal is there to let all nodes know what the latest
jcr state is, so that it a) knows that the persistence manager that
actually does the clustering in some way needs to get the latest data
and most importantly b) can clear its internal caches properly.

BTW: I guess with "datastore" you mean the general concept of storing
Jackrabbit's data, not the specific Jackrabbit DataStore concept for
binaries, right?

>  Is the <Journal> necessary for absolute
> datastore coherency once the JCR has been configured in journaled mode,
> or is it only used to keep concurrent readers and writers synchronized
> with each other?

As noted above, it is necessary to keep all nodes in sync, regardless
whether they are practically read-only or write-only.

Regards,
Alex


> We have a two-node jackrabbit cluster which hosts our application
> configuration data.  We use bundle.OraclePersistenceManager with
> Jackrabbit hitting a non-jta datasource in JBoss.  It works nicely.  We
> have a separate application which serves as a failsafe configuration
> editor, in case an administrator manages to corrupt the configuration
> and leave JBoss unbootable or crippled.  This separate application does
> not have the benefit of the database authentication code in JBoss
> (customer requirements specify that we can't put the password in the
> repository.xml).  We've worked around the issue with for the
> PersistenceManager, but I'd prefer not to have to go through the same
> steps for the DatabaseJournal.
>
>
>
> Will it corrupt the JCR database tables if the journal table is not
> updated when running the failsafe configuration editor?  There would be
> no other readers or writers at the time.  Once the configuration is
> repaired, the failsafe app is shut-down and the JBoss cluster would be
> started again.
>
>
>
> Thanks,
>
> Ryan Hochstetler
>
> Senior Software Engineer
>
> JET Enterprise Team
>
> Raytheon Company
>
>



-- 
Alexander Klimetschek
alexander.klimetschek@day.com