You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Dan Diephouse <da...@mulesource.com> on 2008/01/12 22:17:57 UTC
Problem in Multithreaded Environment
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???
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: Problem in Multithreaded Environment
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 16, 2008 10:55 PM, Dan Diephouse <da...@mulesource.com> wrote:
> Thanks. Follow up question: My data has no unique id or anything associated
> with it. So I'm going to have to generate an id then.
A good way to solve such issues is to think of the content repository
as an advanced file system. How would you name your content if you'd
be storing it as files in a file system instead of nodes in a content
repository?
Even if the node or file name has no real semantics or there is no
clear unique identifier available, I often still try to extract at
least some weakly identifiable information from the content and use
that to generate the node name. Typically I use some normalization to
make the base name a valid JCR name and then add some unique suffix
(perhaps a counter, like you often see done with normal files) if that
name is already taken.
Such names make it much easier for an administrator to manually work
with the content even if your application cares nothing about the
names. For example, if you're storing spreadsheets, can you extract
the title property or previous file name of the spreadsheet and use
that as the basis for the node name?
> I can do an increment type thing like this:
>
> public Node getNode(int nodeName, Node parent) {
> try { return parent.addNode(new Integer(nodeName).toString()) }
> catch (ItemExistsException e) { return getNode(nodeName+1); }
> }
>
> Lets say I have two open transactions where this is occurring at the same
> time. Will Tx#2 see that #1 has added a node named "1" and get an
> ItemExistsException even though I haven't committed Tx#1?
No, they'll end up conflicting. Uncommitted changes are never seen by
other sessions.
> Are there any bundled utilities within jackrabbit that can create unique
> ids across a cluster? Should I just use UUIDs?
There are some related code snippets in the mailing list archives, but
I'd probably use a UUID instead of a counter.
BR,
Jukka Zitting
Re: Problem in Multithreaded Environment
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 16, 2008 9:27 PM, Dan Diephouse <da...@mulesource.com> wrote:
> I have to lock the parent node before I can add child nodes? How does that
> help the situation? Then I have one thread that fails while the other
> succeeds.
>
> Lets say I have a node /spreadsheets and then I have two users using my web
> interface and they both add a spreadsheet to the repository at the same
> time. And spreadsheet nodes are represented by /spreadsheets/spreadsheet .
> Are you saying thats not possible?
Jackrabbit handles such concurrent additions nicely as long as the
added child nodes have separate names. See JCR-584 [1] for the
details.
Unfortunately this does not currently work with same name siblings. If
I recall correctly there were some tricky semantic issues on how such
cases should really be handled.
Have you considered not using same name siblings in your content mode.
See [2] and the related mailing list thread [3] for a rationale why
locally (within a parent) unique node names are considered a better
solution.
[1] https://issues.apache.org/jira/browse/JCR-584
[2] http://wiki.apache.org/jackrabbit/DavidsModel#head-1df0224190c265f5156f037eb3f20e314fa6c4a7
[3] http://www.nabble.com/DM-Rule--4%3A-Beware-of-Same-Name-Siblings.-td11477597.html
BR,
Jukka Zitting
Re: Problem in Multithreaded Environment
Posted by Stefan Guggisberg <st...@gmail.com>.
On Jan 14, 2008 10:44 PM, Dan Diephouse <da...@mulesource.com> 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
>
Re: Problem in Multithreaded Environment
Posted by Stefan Guggisberg <st...@gmail.com>.
hi dan
On Jan 12, 2008 10:19 PM, Dan Diephouse <da...@mulesource.com> 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.
cheers
stefan
>
> Cheers,
>
> - Dan
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
>
Re: Problem in Multithreaded Environment
Posted by Stefan Ivanov <st...@gmail.com>.
Hi Dan
I have the same problem. I tried this with Local and XA Transaction Manager
but still ... :-(
I use 1.3.3 and at the moment I'm happier with the Local Transaction
Manager.
I've done different things to avoid this: reorganization of the data
structure tree, unique node names but the problem is still here.
Stefan
2008/1/12, Dan Diephouse <da...@mulesource.com>:
>
> 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)
>
> Cheers,
> - Dan
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
>
Re: Problem in Multithreaded Environment
Posted by Dan Diephouse <da...@mulesource.com>.
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)
Cheers,
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog