Thank you for the verification. I'll wait. Good luck with the fix. Please let me know if I can help in any way.
2008/2/28, Stefan Guggisberg <[EMAIL PROTECTED]>: > 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 > > >
