OK,
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}_"/>
and
<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
http://www.integrate.co.uk
On 6 Feb 2013, at 11:03, Luke Noel-Storr <[email protected]>
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 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
>
