> It cannot be only that. By the looks of it some part of your code uses > Node#hasProperty after Node#delete, which is illegal and that's what's > causing it. Yes, that's right. The exception is expected behaviour. But why the node's still in the index?
I think it's just a timing problem in our code. It's happening only under race conditions when creating and deleting nodes with multiple threads. Maybe it's because after node.delete() the deleting thread doesn't immediately remove it from the index while another thread accesses the node via index lookup, and of course fails to use the node as it has already the notInUse flag persisted. Seems that the node is then kind of locked. I don't know ... It's a bit weird that it's so easy to bring the database into an inconsistant state with a node still being in the index, but our fix is working for us so far, and I understood what we did wrong. Sorry that I don't have more time to sort it out. But if you really think that it's worth to have a deeper look into it, I could setup a small webapp using the libraries we're using here (it's all available at Github [1]). [1] https://github.com/structr/structr/blob/develop/structr/structr-core/src/main/java/org/structr/rest/constraint/ResourceConstraint.java Greetings Axel _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
