spatial
spatial copied to clipboard
Multiple RTree references created
See http://code.paananen.fi/2012/09/21/working-around-a-neo4j-spatial-spring-data-for-neo4j-bug/ for details
Also see https://github.com/neo4j/spatial/issues/51
Same issue.
Neo4j-Spatial is not thread-safe... Usage should be synchronized using a ReadWriteLock.
Davide, could you put in a test that demostrates the usage so we can refer to it?
On Sat, Sep 22, 2012 at 5:02 AM, Davide Savazzi [email protected]:
Neo4j-Spatial is not thread-safe... Usage should be synchronized using a ReadWriteLock.
— Reply to this email directly or view it on GitHubhttps://github.com/neo4j/spatial/issues/65#issuecomment-8788175.
by @svzdvd :
We can use the root node of the Spatial graph as a lock, this is how SortedTree in graph-collections does:
https://github.com/neo4j/graph-collections/blob/master/src/main/java/org/neo4j/collections/sortedtree/SortedTree.java (see the method acquireLock)
I encountered the issue shown here. I got the error:
org.neo4j.graphdb.NotFoundException: More than one relationship[RTREE_REFERENCE, INCOMING] found for NodeImpl#177299
I am using: Neo4j 1.8.1 Neo4j spatial 0.11-SNAPSHOT gremlin-groovy 2.2.0 (I have now downgraded to 1.5 as I read that is what is supported) Spring-Data-Neo4j 2.2.0.RELEASE
I encountered the issue in a single-threaded situation when calling: <LandTile> Iterable<LandTile> org.springframework.data.neo4j.repository.CRUDRepository.save(Iterable<LandTile> entities)
In a list that included new entities without Ids and entities with Ids and new properties that needed to be updated.
Performing the following operation before attempting to persist the land tiles seems to avoid the issue, but obviously it is not the best solution:
public void persistLandTiles(List<LandTile> tilesToPersist) {
List<LandTile> tilesToDelete = new ArrayList<LandTile>();
for (LandTile tile : tilesToPersist) {
LandTile oldTile = landTileRepository.findWithinWellKnownText(LandTile.WKT_INDEX,
tile.getWkt()).singleOrNull();
if (oldTile != null) {
tilesToDelete.add(oldTile);
}
tile.setId(null);
}
this.deleteLandTiles(tilesToDelete);
landTileRepository.save(tilesToPersist);
}
I can confirm that we are seeing the same issue with Neo4j 2.0.2 and 0.12-neo4j-2.0.2-SNAPSHOT. We are not using SDN.
My belief is that is has to do with deleting and re-adding nodes to the index.
I thought I'd look into this issue a little, and follow up on Davide's suggestion to use aquireLock as in SortedTree. However, I'm not clear at all how that code works. It appears to delete a property in acquireLock, and never re-create it (or in any way release any lock). Git blame also does not tell me who the author is, so I don't know who to ask about the thinking behind this. See https://github.com/neo4j-contrib/graph-collections/commit/edc3b8a97690dcb9ff24f5686d88a5f8990800ec
Any ideas?
I think when you try to delete a property (even if it doesn't exist) you acquire a Write Lock on the PropertyContainer. Maybe this code was written when you couldn't explicitly manage Locks. Now you can use Transaction.acquireReadLock(PropertyContainer), Transaction.acquireWriteLock(PropertyContainer) and Lock.release().
btw the "referenced" message is some strange Git misbehavior, because I referenced jexp/batch-import/#65
, not this
EDIT: does anyone have an idea why Git checks web link headers for issue tags??? ':-D