Broken data consistency?

[mmatloka]

Hello,

I'am doing some integrational tests for my app. Approximatelly I'am executing the following operations:

Add node of type A

Add node of type B which refers to node of type A (reference, not weak reference)

Try to delete node of type A

org.modeshape.jcr.cache.ReferentialIntegrityException (expected)

Get all nodes of type B with their references

javax.jcr.ItemNotFoundException during getting referenced object (which I tried to delete) (?!)

However on modeshape-rest i see all these objects exists. All mentioned operations works sperately and are tested in my app. Only this removing referenced object brings these additional problems.

I unfortunatelly cant post my code used in this case. Has anyone observed such problems? Are there any existing tests for this case?

Modeshape 3.0.0

[rhauch]

We have a number of unit and integration tests that verify that you can remove the B node and then remove A (but remove A before B and save).

Be sure that you're not still using the same session that you used to try (and fail) to remove A. The referenential integrity exception happens on save, which means that if save does fail, the session still has in its transient state the removal of A (meaning the node doesn't actually exist in that session, but the session's transient state is not valid). You can either call "refresh(false)" on the session to remove all transient and unsaved changes, or simply close the session and get a new one.

(You may wonder why we don't identify the referential integrity problem when you try to remove node A. The reason is that you might also want to remove node B at the same time, but you shouldn't have to order the removals based upon references. In fact, doing so might easily become quite tricky if not impossible for some patterns of references. The JCR specification instead says that referential integrity should be checked upon 'save()', making it far easier for applications to remove all the nodes they want to remove in any order they want to remove them.)

If you're still having trouble, please create a standalone test case that demonstrates the problem.

[mmatloka]

Yes, I was using the same session. Now I've changed my code, that before every operation logout and login are done. However it still does not work how I expected. I run my test suite performing basic crud operations on type which has references (some of them fails), and after that I get situation in which I cannon perform any delete. I can not delete used by nothing object, even though I'm creating everytime new session. Everytime i get ReferentialIntegrityException . But after restart, it again works like before (some tests fails) and again I'm in situation in which i cannot perform any delete. It theretically indicates it should be my problems with session, but I am doing now logout and login (and assign new session).

Tested code unfortunateely has to save session after every (chaning state)operation.

Edit:

I'm studying further this situation. Test which brings mentioned situation assigns to reference property object which was already there assigned (so theoretically it should not change anything but brings referential integrity exception?). After this failed update like mentioned before e.g. remove operation stopps working even though it is a new session.

Edit2:

What I have debugged so far. When reference proprty is set to the same value during update operation, in SessionNode class, removeStrongReferrer is executed, adds to removedStrong key, then addStrongReferrer is executed, adds to addedStrong key, removes from removedStrong added before. But in reality state has not changed, but still operations result addedStrong contains new value.

So it seems that node probably might then contain two references to the same object (one invalid). So during delete (of that referenced value) it fails due to that second exising somewhere reference  (first is removed with referrer) which is invalid and 'floats' somewhere in the system?

[rhauch]

Thanks for helping track this down and debugging what is happening. Please log an issue in our JIRA.