On Jan 14, 2008 10:44 PM, Dan Diephouse <[EMAIL PROTECTED]> wrote: > > Dan Diephouse wrote: > Stefan Guggisberg wrote: > > you'll get this exception when 2 threads concurrently modify the same item > and the changes cannot be merged. > > for some background information see > http://issues.apache.org/jira/browse/JCR-584. > > > in order to avoid such situations you could apply a JCR lock on the > node about to be modified. > > OK so my situation is that Thread #1 creates node A and then Thread #2 adds > node B. The issue seems to say that that isn't supported yet? Can you > confirm? > > Locking doesn't really help in this scenario unfortunately. Thread #1 > creates node A before Thread #2 can access it. So if it was locked, then > that wouldn't help at all as far as I can see. Am I missing something about > locks? > > Thanks for the response! > > > Actually, I did some more debugging and its looking like they're both > trying to add a child to an existing parent node at the same time. I'm > logging messages like this at the same time: > > Thread #1: Created node /parent/child with id > 122b0a4f-ba59-4565-bad8-2be9a3af97ae and parent > b3c8126e-8c84-4735-b3b6-a0b24708beeb > Thread #2: Created node /parent/child with id > 7e443962-f1f6-4c2d-9d8c-0d05a3e7d8e8 and parent > b3c8126e-8c84-4735-b3b6-a0b24708beeb > > And *always* one of the threads will fail will this when I call > session.save():
that's expected and in accordance with the spec. both threads create a node named 'child' on the same parent node. that's a potential name collision (depending on whether same-name siblings are allowed at that specific location). JCR locks can be used to prevent such situations. cheers stefan > > Exception in thread "pool-1-thread-1" > org.springframework.dao.ConcurrencyFailureException: Invalid item state; > nested exception is javax.jcr.InvalidItemStateException: > 8e7e280d-c8ff-429e-bb69-a022885b5d61 has been modified externally > Caused by: javax.jcr.InvalidItemStateException: > 8e7e280d-c8ff-429e-bb69-a022885b5d61 has been modified externally > at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1218) > > at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:849) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.springmodules.jcr.JcrTemplate$LogoutSuppressingInvocationHandler.invoke(JcrTemplate.java:712) > at $Proxy2.save(Unknown Source) > > I did a bit of cleanup so I can actually produce this reliably. Any further > ideas? It seems like this type of things should work... > > > - Dan > -- > Dan Diephouse > MuleSource > http://mulesource.com | http://netzooid.com/blog >
