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 <[email protected]> wrote:
> On 5 February 2013 20:57, Jeroen Reijn <[email protected]> wrote:
>> On Mon, Feb 4, 2013 at 11:10 AM, Luke Noel-Storr
>> <[email protected]> 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
