jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Noel-Storr <luke.noel-st...@integrate.co.uk>
Subject Re: Clustering Question
Date Wed, 06 Feb 2013 12:11:29 GMT

I bit more experimenting, and I think I can answer my own questions a bit:

I believe it is just the version and workspace FileSystem that needs to be unique to each
node, and I have discovered that environment variables can be embedded in prefixes, so, for
the version and workspace filesystem schema prefixes I have:

  <param name="schemaObjectPrefix" value="${wsp.name}_${node.id}_"/>


  <param name="schemaObjectPrefix" value="${wsp.name}_${node.id}_"/>

And, to give the nodes unique ids, but with a single repository.xml, I have:

  <Cluster id="${node.id}">

Does this seem like I'm on the right track?

Many Thanks,

Luke Noel-Storr.

Integrated Publishing Solutions Ltd.
Tel: +44 (0)1926 889199

On 6 Feb 2013, at 11:03, Luke Noel-Storr <luke.noel-storr@integrate.co.uk> wrote:

> Hi,
> Thanks for the answers, both.
> Regarding locks, from what I've read session locks won't work, but object locks should.
 Can anyone confirm this.
> I think I will need to use locks as, as far as I can tell, JCR offers no means of specifying
unique keys, or of doing an atomic query+update.  The only two ways I've seen recommended
of doing this are using locks, or using single name siblings, as my "unique key" is made of
a number of fields, single name siblings seem to be an unlikely solution, unless the name
I use is some combination of all the properties and their values.
> Also, regarding the FileSystem, where the clustering page in the wiki says:
>> Each cluster node needs its own (private) workspace level and version FileSystem
>>       (only those within the workspace and versioning configuration; the ones in
>>      repository.xml and workspace.xml file)
> Does this mean that I will not be able to use Oracle persistence for the version table
and the workspace file system, or, if I do, will each node need to use a different schema
object prefix pre-fix? (and can the node id be automatically added to the prefix, like value="${node.id}_version"?)
> Regarding using Oracle, I seem to have come across a strange bug, which I've not yet
been able to identify.  When starting up a new repository on a clean DB, you get an error
"ORA-00955: name is already used by an existing object" for every set of tables it tries to
create.  If you restart it then gets past the error, but hits it again for the next set of
tables.  This meant I needed to restart 4 times before it would run, once for the default
workspace, once for versions, and one for security, and then the final time it worked.  I'll
try and have a dig into this when I get a bit more time, but, wondered if anyone else had
experienced this.
> I lost about two days to the bug, as every time I hit it I tried clearing the database,
changing some configuration, or settings, and then restarting.  It was only by chance that
I finally found that a brute force effort would finally get it running smoothly.
> Many Thanks,
> Luke Noel-Storr.
> ----------------
> Integrated Publishing Solutions Ltd.
> Tel: +44 (0)1926 889199
> http://www.integrate.co.uk
> On 5 Feb 2013, at 22:08, Ian Boston <ieb@tfd.co.uk> wrote:
>> On 5 February 2013 20:57, Jeroen Reijn <j.reijn@onehippo.com> wrote:
>>> On Mon, Feb 4, 2013 at 11:10 AM, Luke Noel-Storr
>>> <luke.noel-storr@integrate.co.uk> wrote:
>>>> Also, and advice on locking would be appreciated.
>>> Sorry can't help you with this one.
>> JCR locks will work within the same JVM but will not propagate
>> reliably throughout a cluster since the replay of the journal  (which
>> is used to propagate the lock) is not synchronised with the writing of
>> that journal. ie cluster nodes can fall behind.
>> If you need cluster wide locks then you should probably use separate
>> component. Since you have Oracle in the mix, a transactional lock
>> within Oracle will be the easiest way of achieving this. Perhaps a
>> table with a sha1of the path to be locked will work, with a simple IN
>> query to select descendents. YMMV.
>> HTH
>> Ian

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message