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 11:03:07 GMT
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 the
>      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


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