jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: SessionTest.testSaveInvalidStateException vs OAK
Date Wed, 06 Jun 2012 15:16:07 GMT

On 6.6.12 14:20, Julian Reschke wrote:
> Hi there,
> I was just checking why this test fails.
> Test description:
> Tries to save a node using {@link javax.jcr.Session#save()} that was
> already deleted by an other session.
> <p>
> Procedure: <ul>
> <li>Creates a new node with session 1, saves it, adds a child node.</li>
> <li>Access new node with session 2,deletes the node, saves it.</li>
> <li>session 1 tries to save modifications .</li> </ul> This should
> an {@link javax.jcr.InvalidItemStateException}.
> <p>
> Prerequisites:
> <ul> <li><code>javax.jcr.tck.nodetype</code> must accept children
of same
> nodetype</li> </ul>
> At first glance, this seems to be another case of where the test needs
> to refresh() before saving, because in Oak, the session doesn't
> necessarily have the latest changes.

This is necessary in any case and should be fixed in the test case.

> However, that doesn't seem to fix it.
> What seems to happen is that the save() operation happens; but the
> resulting state is that the node that was just modified does not exist
> in the repository.

This is caused by the way refresh(true) is currently implemented. It 
does basically a rebase operation: it re-applies all changes of the 
current session to the current trunk. Now when a node does not exist any 
more in trunk and there are changes to the sub tree rooted at that node, 
these changes are silently discarded.

> We need to find out whether this is (a) an OAK bug, (b) a test bug, or
> (c) an expected case of non-compliance.

Is the behaviour tested by testSaveInvalidStateException really mandated 
by the spec? Is it an edge case?

I quickly checked with Jackrabbit 2 and found that while the 
InvalidItemStateException is thrown there, this is not really useful and 
also seems somewhat strange: on one hand, the node in question is not 
there any more (if you try to get or remove it) but it still blocks the 
session from being saved.


> Best regards, Julian

View raw message