hi alexander On Tue, Feb 26, 2008 at 12:22 PM, Foo Bar <[EMAIL PROTECTED]> wrote: > Hi. > > I have just made my first attempt to use Jackrabbit in a bigger > project, and I'm having problems with concurrent access. > > I'm using jackrabbit 1.4 with the example repository.xml in JBoss 4.2.2.GA. > > The first test I made is simple. I tried to change an implementation > that currently uses a filesystem to store files to use jackrabbit. > Users upload files, these get unique id:s and I save them in a flat > directory: > > root > | > files > |-1 > |-2 > |-3 > etc.. > > Each file-node is created according to the recipe at > http://wiki.apache.org/jackrabbit/ExamplesPage (jcr:content subnode > etc). The save is as simple as possible; I get the session, create the > file subnode with binary content and logout. > The id:s are fetched from a db (auto-increment), so they are unique > across transactions. > > The saving works fine, until I start hitting the page with a few > (tenths of) simultaneous uploads. I then get validation exceptions, > telling me about conflicting changes: > > javax.jcr.InvalidItemStateException: > 6570ddc8-29a7-4335-a9ca-76dc98687d22: the item cannot be saved because > it has been modified externally. > at > org.apache.jackrabbit.core.ItemImpl.getTransientStates(ItemImpl.java:378) > at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1083) > at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:896) > at > org.apache.jackrabbit.jca.JCASessionHandle.save(JCASessionHandle.java:178) > > I've read the discussion here: > http://www.nabble.com/Problem-in-Multithreaded-Environment-td14779040.html > (nabble is down, google cache here: > > http://66.102.9.104/search?q=cache:jqbwF-fsAjoJ:www.nabble.com/Problem-in-Multithreaded-Environment-td14779040.html) > > This discussion, together with the issue at > http://issues.apache.org/jira/browse/JCR-584 basically says that it > should be ok to have several sessions concurrently adding subnodes to > a node, without any problems. The JIRA issue only explicitly says that > two sessions concurrently can add subnodes, and I assumed this to be > valid for any number of sessions. Is this a correct assumption?
there's a caveat when adding samename-sibling nodes. the current implementation of NodeStateMerger doesn't merge concurrently added samename sibling nodes. this only applies for the 1st entry, i.e. when 2 sessions try to add a 'foo[1]' child node; see the @todo comment in o.a.j.core.state.NodeStateMerger#merge. as a result you would see an Exception like the one mentioned above. apart from that you might run into JCR-1359. i am currently working on this issue. i have made some progress but wasn't able to resolve it completely yet. > > Is there anything I should keep in mind when trying to make this work? > Any properties who need to be set on nodes or in workspace? Any save > order that might cause problems? > > I'm having trouble reproducing the problem in unit tests, so any hints > as to why this is happening would be greatly appreciated. > > I don't really see serializing access as an option, since the plan is > to have many concurrent saves. I therefore ruled out locks. Is it true > that locks always imply serial access? serial write access that is, yes. cheers stefan > > > Regards > > Alexander >
