jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: SessionTest.testSaveInvalidStateException vs OAK
Date Wed, 06 Jun 2012 15:28:14 GMT
On 2012-06-06 17:16, Michael Dürig wrote:
> 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
throw
>> 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.

But the test case currently does not call refresh() -- so is the refresh 
implied by save()?

>> 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.

I agree that in this situation, you can only get an exception that 
doesn't really help, or a silent data loss. Not sure what's better, and 
also not sure what the spec requires here...

Best regards, Julian

Mime
View raw message