jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: InvalidItemStateException with concurrent threads
Date Fri, 20 Mar 2009 12:00:53 GMT
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.

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

View raw message