Luke, Where are you defining the values for those property variables? I'm kind of in the same boat as you right now and have had similar questions about cluster configuration.
Sent from my iPhone On Feb 6, 2013, at 4:11 AM, Luke Noel-Storr <[email protected]> wrote: > 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 >
