Stefan Guggisberg wrote:
hi dan
On Jan 12, 2008 10:19 PM, Dan Diephouse <[EMAIL PROTECTED]> wrote:
Dan Diephouse wrote:
Heya, I think I'm probably doing something pretty stupid here, but I'm
having a few problems using Jackrabbit in a multithreaded environment.
If you can imagine I have this scenario:
Thread #1 running inside my unit test which is doing stuff to the
repository all in one session.
Thread #2 which is reading stuff inside the repository and updating
some nodes
I think occasionally these threads collide though and start modifying
the same node. Then I starting getting things like:
javax.jcr.RepositoryException: failed to create transient state:
there's already a property state instance with id
1d038015-6c48-4654-a685-1dcf57a6bf6f/{http://www.jcp.org/jcr/1.0}mixinTypes:
there's already a property state instance with id
1d038015-6c48-4654-a685-1dcf57a6bf6f/{http://www.jcp.org/jcr/1.0}mixinTypes
at
org.apache.jackrabbit.core.PropertyImpl.getOrCreateTransientItemState(PropertyImpl.java:97)
at
org.apache.jackrabbit.core.PropertyImpl.restoreTransient(PropertyImpl.java:143)
at
org.apache.jackrabbit.core.ItemImpl.restoreTransientItems(ItemImpl.java:734)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1233)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:849)
...
Caused by: org.apache.jackrabbit.core.state.ItemStateException:
there's already a property state instance with id
1d038015-6c48-4654-a685-1dcf57a6bf6f/{http://www.jcp.org/jcr/1.0}mixinTypes
at
org.apache.jackrabbit.core.state.SessionItemStateManager.createTransientPropertyState(SessionItemStateManager.java:629)
at
org.apache.jackrabbit.core.PropertyImpl.getOrCreateTransientItemState(PropertyImpl.java:90)
... 42 more
Or:
javax.jcr.RepositoryException: failed to create transient state:
there's already a property state instance with id
1d038015-6c48-4654-a685-1dcf57a6bf6f/{http://www.jcp.org/jcr/1.0}uuid:
there's already a property state instance with id
1d038015-6c48-4654-a685-1dcf57a6bf6f/{http://www.jcp.org/jcr/1.0}uuid
at
org.apache.jackrabbit.core.PropertyImpl.getOrCreateTransientItemState(PropertyImpl.java:97)
at
org.apache.jackrabbit.core.PropertyImpl.restoreTransient(PropertyImpl.java:143)
at
org.apache.jackrabbit.core.ItemImpl.restoreTransientItems(ItemImpl.java:734)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1233)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:849)
....
Caused by: org.apache.jackrabbit.core.state.ItemStateException:
there's already a property state instance with id
1d038015-6c48-4654-a685-1dcf57a6bf6f/{http://www.jcp.org/jcr/1.0}uuid
at
org.apache.jackrabbit.core.state.SessionItemStateManager.createTransientPropertyState(SessionItemStateManager.java:629)
at
org.apache.jackrabbit.core.PropertyImpl.getOrCreateTransientItemState(PropertyImpl.java:90)
... 42 more
If the second thread was accessing a node created by the first thread
and the node wasn't saved yet, would that explain these errors?
Any ideas how to avoid this???
One other thing. Those exceptions are from thread #2. I get this
exception from thread #1:
org.springframework.dao.ConcurrencyFailureException: Invalid item state;
nested exception is javax.jcr.InvalidItemStateException: /activities:
the node cannot be saved because it has been modified externally.
Caused by: javax.jcr.InvalidItemStateException: /activities: the node
cannot be saved because it has been modified externally.
at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:969)
at
org.apache.jackrabbit.core.ItemImpl.persistTransientItems(ItemImpl.java:687)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1198)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:849)
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!
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
|
