Wow,
thanks, lots of suggestions :)
I think I am in the situation where there are lots of users contending
on a smaller number of items, which puts me into the realm of
possibilities a,b,c mentioned by Jukka.
a) these are completely unmergable as Thomas points out.
b) done some tests with something close to Lock.with() and finding the
first non transient ancestor, although this works reliably, I went as
far as 200 threads with 200 operations and saw no problems....
however, this is in a cluster and the number of journals written was
about 4.5x that seen with a serialized update. One run I did showed 4K
journal records when the work was performed on a single thread with a
single session compared to 19K journal records with a 10 threads doing
the work concurrently. Since writing journal records is showing up as
a significant load on the db, and generates load on all nodes in the
cluster, I am less keen on explicit locking.
c) Making the operations fail is certainly an option, provided I have
a retry mechanism at the transaction boundaries. I think this might be
possible, but its going to force all the code to be really good about
its transactional boundaries. (no bad thing).
As Julian suggests, I could do a save more frequently on new folders
making recovery possible and that will certainly decrease complexity,
however this will increase the number or journal records (although
probably not the total size). This sounds like its worth a try.
I am also trying a separate lock manager as we already have cluster
replicated caches implemented into which we can easily put the lock
objects, and considering retrying the operation at the servlet request
filter level.
Thank you for you help, I will try and share the outcome to help
anyone following the same the same pathway.
Ian
On 20 Mar 2009, at 11:29, Julian Reschke wrote:
Ian Boston wrote:
...
Unfortunately building a hashed tree of folders results in non-
mergable changes.
before
/store/ab
thread1
/store/ab/ed/8c/data.json
thread2
/store/ab/ed/8c/otherdata.json
the creation of ed is a non mergable change, and I don't fancy
creating the 255^3 nodes to avoid the problem.
...
How about creating the intermediate folders on demand, but in
separate JCR save operations? In that case at least the exception
handling gets much simpler, because the only reason the single
createNode/nt:folder would fail would be a race condition - so after
the exception you'd just check whether the folder was created by a
different thread, in which case you wouldn't need to retry...
BR, Julian
