You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Carlos Villegas <ca...@uniscope.jp> on 2006/02/27 09:52:40 UTC
ItemStateException
What does the following exception mean:
javax.jcr.InvalidItemStateException:
d35eb7b6-ca1a-4c18-98fc-0aa0ee9b8987: the item cannot be saved because
it has been modified externally.
There's only one application using the repository. What could be happening?
Carlos
Re: ItemStateException
Posted by Carlos Villegas <ca...@uniscope.jp>.
Stefan Guggisberg wrote:
> On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
>
>>Stefan Guggisberg wrote:
>>
>>>On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
>>>
>>>
>>>>Is there a way to list the currently open sessions in the server, so I
>>>>can trace this problem?
>>>
>>>
>>>no. but you don't need it because your problem is not caused by
>>>dangling sessions.
>>
>>but what if a dangling session has unsaved changes due to an unrelated
>>application error?
>
>
> unsaved changes of a dangling/abandoned session are 'session-local'
> only and therefore cannot be the cause of your problem.
Finally I got it! Sorry it took a while!
I'll try locking node...
Thanks,
Carlos
Re: ItemStateException
Posted by Stefan Guggisberg <st...@gmail.com>.
On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
> Stefan Guggisberg wrote:
> > On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
> >
> >>Is there a way to list the currently open sessions in the server, so I
> >>can trace this problem?
> >
> >
> > no. but you don't need it because your problem is not caused by
> > dangling sessions.
>
> but what if a dangling session has unsaved changes due to an unrelated
> application error?
unsaved changes of a dangling/abandoned session are 'session-local'
only and therefore cannot be the cause of your problem.
>
> Carlos
>
Re: ItemStateException
Posted by Carlos Villegas <ca...@uniscope.jp>.
Stefan Guggisberg wrote:
> On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
>
>>Is there a way to list the currently open sessions in the server, so I
>>can trace this problem?
>
>
> no. but you don't need it because your problem is not caused by
> dangling sessions.
but what if a dangling session has unsaved changes due to an unrelated
application error?
Carlos
Re: ItemStateException
Posted by Stefan Guggisberg <st...@gmail.com>.
On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
> Is there a way to list the currently open sessions in the server, so I
> can trace this problem?
no. but you don't need it because your problem is not caused by
dangling sessions.
>
> Carlos
>
> Carlos Villegas wrote:
> > Hmmm... We had problems before because the application didn't close the
> > sessions on exit and the RMI client leaves them open on the server even
> > though the client VM exits. We may still have session leakage.
> > Shouldn't the RMI server close sessions if the client dies, or there's
> > no way to know that a client has died?
> >
> > Thanks for the explanation!
> >
> > Carlos
> >
> > Stefan Guggisberg wrote:
> >
> >> On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
> >>
> >>> What does the following exception mean:
> >>>
> >>> javax.jcr.InvalidItemStateException:
> >>> d35eb7b6-ca1a-4c18-98fc-0aa0ee9b8987: the item cannot be saved because
> >>> it has been modified externally.
> >>>
> >>> There's only one application using the repository. What could be
> >>> happening?
> >>
> >>
> >>
> >> this exception indicates that you have 2 separate sessions that try to
> >> modify
> >> the *same* item.
> >>
> >> the following code fragment illustrates this:
> >>
> >> Node a1 = session1.getRootNode().getNode("a");
> >> Node a2 = session2.getRootNode().getNode("a");
> >>
> >> // session 1 modifies node a
> >> a1.addNode("b");
> >> // session 2 modifies node a
> >> a2.addNode("c");
> >>
> >> // session 1 saves its changes
> >> a1.save();
> >>
> >> // session 2 tries to save its changes but gets
> >> // an InvalidItemStateException because its
> >> // changes have become stale
> >> a2.save(); // throws
> >>
> >>
> >> you can avoid such situations if you lock the node before
> >> you start modifiying it.
> >>
> >> cheers
> >> stefan
> >>
> >>
> >>> Carlos
> >>>
> >>
> >>
> >
> >
>
>
Re: ItemStateException
Posted by Carlos Villegas <ca...@uniscope.jp>.
Is there a way to list the currently open sessions in the server, so I
can trace this problem?
Carlos
Carlos Villegas wrote:
> Hmmm... We had problems before because the application didn't close the
> sessions on exit and the RMI client leaves them open on the server even
> though the client VM exits. We may still have session leakage.
> Shouldn't the RMI server close sessions if the client dies, or there's
> no way to know that a client has died?
>
> Thanks for the explanation!
>
> Carlos
>
> Stefan Guggisberg wrote:
>
>> On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
>>
>>> What does the following exception mean:
>>>
>>> javax.jcr.InvalidItemStateException:
>>> d35eb7b6-ca1a-4c18-98fc-0aa0ee9b8987: the item cannot be saved because
>>> it has been modified externally.
>>>
>>> There's only one application using the repository. What could be
>>> happening?
>>
>>
>>
>> this exception indicates that you have 2 separate sessions that try to
>> modify
>> the *same* item.
>>
>> the following code fragment illustrates this:
>>
>> Node a1 = session1.getRootNode().getNode("a");
>> Node a2 = session2.getRootNode().getNode("a");
>>
>> // session 1 modifies node a
>> a1.addNode("b");
>> // session 2 modifies node a
>> a2.addNode("c");
>>
>> // session 1 saves its changes
>> a1.save();
>>
>> // session 2 tries to save its changes but gets
>> // an InvalidItemStateException because its
>> // changes have become stale
>> a2.save(); // throws
>>
>>
>> you can avoid such situations if you lock the node before
>> you start modifiying it.
>>
>> cheers
>> stefan
>>
>>
>>> Carlos
>>>
>>
>>
>
>
Re: ItemStateException
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
> > I'm currently trusting on the RMI distributed garbage collector (DGC)
> > to clean up unclosed sessions. The end result should be similar to
> > locally abandoned sessions.
> > [...]
>
> How long before an dangling session is closed this way? Is there some
> expiry time we can configure?
The RMI DGC lease time is controlled by the java.rmi.dgc.leaseValue
system property. See the link below for more details:
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/rmi.html#garbage
But, as mentioned by Stefan, this is probably not the cause of your problem.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: ItemStateException
Posted by Carlos Villegas <ca...@uniscope.jp>.
Jukka Zitting wrote:
> Hi,
>
> On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
>
>>Hmmm... We had problems before because the application didn't close the
>>sessions on exit and the RMI client leaves them open on the server even
>>though the client VM exits. We may still have session leakage.
>>Shouldn't the RMI server close sessions if the client dies, or there's
>>no way to know that a client has died?
>
>
> I'm currently trusting on the RMI distributed garbage collector (DGC)
> to clean up unclosed sessions. The end result should be similar to
> locally abandoned sessions.
>
> An alternative would be for the server to explicitly poll the client
> for status or to require the client to periodically renew a "session
> lease", but that seems like an unnecessary complication given the DGC.
> I may end up adding such a feature as a part of JCR-206, but that's
> low priority at the moment.
How long before an dangling session is closed this way? Is there some
expiry time we can configure?
Carlos
Re: ItemStateException
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
> Hmmm... We had problems before because the application didn't close the
> sessions on exit and the RMI client leaves them open on the server even
> though the client VM exits. We may still have session leakage.
> Shouldn't the RMI server close sessions if the client dies, or there's
> no way to know that a client has died?
I'm currently trusting on the RMI distributed garbage collector (DGC)
to clean up unclosed sessions. The end result should be similar to
locally abandoned sessions.
An alternative would be for the server to explicitly poll the client
for status or to require the client to periodically renew a "session
lease", but that seems like an unnecessary complication given the DGC.
I may end up adding such a feature as a part of JCR-206, but that's
low priority at the moment.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: ItemStateException
Posted by Stefan Guggisberg <st...@gmail.com>.
On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
> Hmmm... We had problems before because the application didn't close the
> sessions on exit and the RMI client leaves them open on the server even
> though the client VM exits. We may still have session leakage.
the above mentioned exception is not caused by sessions that were closed
properly. the code fragment clearly demonstrates the 'issue'.
cheers
stefan
> Shouldn't the RMI server close sessions if the client dies, or there's
> no way to know that a client has died?
>
> Thanks for the explanation!
>
> Carlos
>
> Stefan Guggisberg wrote:
> > On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
> >
> >>What does the following exception mean:
> >>
> >>javax.jcr.InvalidItemStateException:
> >>d35eb7b6-ca1a-4c18-98fc-0aa0ee9b8987: the item cannot be saved because
> >>it has been modified externally.
> >>
> >>There's only one application using the repository. What could be happening?
> >
> >
> > this exception indicates that you have 2 separate sessions that try to modify
> > the *same* item.
> >
> > the following code fragment illustrates this:
> >
> > Node a1 = session1.getRootNode().getNode("a");
> > Node a2 = session2.getRootNode().getNode("a");
> >
> > // session 1 modifies node a
> > a1.addNode("b");
> > // session 2 modifies node a
> > a2.addNode("c");
> >
> > // session 1 saves its changes
> > a1.save();
> >
> > // session 2 tries to save its changes but gets
> > // an InvalidItemStateException because its
> > // changes have become stale
> > a2.save(); // throws
> >
> >
> > you can avoid such situations if you lock the node before
> > you start modifiying it.
> >
> > cheers
> > stefan
> >
> >
> >>Carlos
> >>
> >
> >
>
>
Re: ItemStateException
Posted by Carlos Villegas <ca...@uniscope.jp>.
Hmmm... We had problems before because the application didn't close the
sessions on exit and the RMI client leaves them open on the server even
though the client VM exits. We may still have session leakage.
Shouldn't the RMI server close sessions if the client dies, or there's
no way to know that a client has died?
Thanks for the explanation!
Carlos
Stefan Guggisberg wrote:
> On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
>
>>What does the following exception mean:
>>
>>javax.jcr.InvalidItemStateException:
>>d35eb7b6-ca1a-4c18-98fc-0aa0ee9b8987: the item cannot be saved because
>>it has been modified externally.
>>
>>There's only one application using the repository. What could be happening?
>
>
> this exception indicates that you have 2 separate sessions that try to modify
> the *same* item.
>
> the following code fragment illustrates this:
>
> Node a1 = session1.getRootNode().getNode("a");
> Node a2 = session2.getRootNode().getNode("a");
>
> // session 1 modifies node a
> a1.addNode("b");
> // session 2 modifies node a
> a2.addNode("c");
>
> // session 1 saves its changes
> a1.save();
>
> // session 2 tries to save its changes but gets
> // an InvalidItemStateException because its
> // changes have become stale
> a2.save(); // throws
>
>
> you can avoid such situations if you lock the node before
> you start modifiying it.
>
> cheers
> stefan
>
>
>>Carlos
>>
>
>
Re: ItemStateException
Posted by Carlos Villegas <ca...@uniscope.jp>.
I think this is also the cause of the node state getting corrupted as I
reported in another post. After this error, it seems, the property I was
trying to save, is registered in the node but the item state doesn't
exist. The property reports as existing but if I try to set it, it
throws an ItemNotFoundException. Even though the session is not required
to be thread-safe, shouldn't jackrabbit maintain the repository
consistent at all times?
Carlos
Jukka Zitting wrote:
> Hi,
>
> On 2/28/06, Carlos Villegas <ca...@uniscope.jp> wrote:
>
>>Could this error happen if two threads are working simultaneously on the
>>same session?
>
>
> This might well be the cause. A Session should only be accessed from a
> single thread as it is not required to be thread-safe. See the section
> 7.5 Thread-Safety Requirements of the JCR specification.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
Re: ItemStateException
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 2/28/06, Carlos Villegas <ca...@uniscope.jp> wrote:
> Could this error happen if two threads are working simultaneously on the
> same session?
This might well be the cause. A Session should only be accessed from a
single thread as it is not required to be thread-safe. See the section
7.5 Thread-Safety Requirements of the JCR specification.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: ItemStateException
Posted by Carlos Villegas <ca...@uniscope.jp>.
Could this error happen if two threads are working simultaneously on the
same session?
I have a InputStream property in one node and spawn a thread to pipe an
OutputStream from some process. It seems, in a slow machine, since the
process already closed the OutputStream, it goes on saving other
properties in the same node. However, the piping thread may still be
executing the final node.save(). The interesting thing is that I
reversed the calls and now I don't see the error anymore. In other
words, I execute the pipe at the end, and then return control to the
interactive GUI, so no more JCR operations happens for a while.
Carlos
Stefan Guggisberg wrote:
> On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
>
>>What does the following exception mean:
>>
>>javax.jcr.InvalidItemStateException:
>>d35eb7b6-ca1a-4c18-98fc-0aa0ee9b8987: the item cannot be saved because
>>it has been modified externally.
>>
>>There's only one application using the repository. What could be happening?
>
>
> this exception indicates that you have 2 separate sessions that try to modify
> the *same* item.
>
> the following code fragment illustrates this:
>
> Node a1 = session1.getRootNode().getNode("a");
> Node a2 = session2.getRootNode().getNode("a");
>
> // session 1 modifies node a
> a1.addNode("b");
> // session 2 modifies node a
> a2.addNode("c");
>
> // session 1 saves its changes
> a1.save();
>
> // session 2 tries to save its changes but gets
> // an InvalidItemStateException because its
> // changes have become stale
> a2.save(); // throws
>
>
> you can avoid such situations if you lock the node before
> you start modifiying it.
>
> cheers
> stefan
>
>
>>Carlos
>>
>
>
Re: ItemStateException
Posted by Stefan Guggisberg <st...@gmail.com>.
On 2/27/06, Carlos Villegas <ca...@uniscope.jp> wrote:
> What does the following exception mean:
>
> javax.jcr.InvalidItemStateException:
> d35eb7b6-ca1a-4c18-98fc-0aa0ee9b8987: the item cannot be saved because
> it has been modified externally.
>
> There's only one application using the repository. What could be happening?
this exception indicates that you have 2 separate sessions that try to modify
the *same* item.
the following code fragment illustrates this:
Node a1 = session1.getRootNode().getNode("a");
Node a2 = session2.getRootNode().getNode("a");
// session 1 modifies node a
a1.addNode("b");
// session 2 modifies node a
a2.addNode("c");
// session 1 saves its changes
a1.save();
// session 2 tries to save its changes but gets
// an InvalidItemStateException because its
// changes have become stale
a2.save(); // throws
you can avoid such situations if you lock the node before
you start modifiying it.
cheers
stefan
>
> Carlos
>