cancel
Showing results for 
Search instead for 
Did you mean: 

Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.

Issues importing RDF in the middle of a transaction

I'm running into an issue where a CALL semantics.importRDFSnippet (the 3.5 version of neosemantics) in a transaction is blocking indefinitely.

Are there any caveats/issues to be aware of when importing RDF as part of a user-level transaction?

In this particular case, the transaction includes a preceding action that deletes a couple of edges from the same node that the importRDF operation adds some (non-conflicting) edges.

Looking at the neosemantics source code, it appears to me that the import step is implemented as a separate transaction, and so perhaps there is no way to do an import operation as part of a broader transaction?

2 REPLIES 2

When adding or deleting edges, both start and end nodes are locked so if the transaction that deletes the edges has not been terminated when the one trying to add additional ones starts, I suspect there is a chance the second one will be waiting indefinitely until the previous one releases the lock on the node (via either commit or rollback).

Am I interpreting your description correctly?

If not, it would be great to get an example to try and reproduce the issue.

Cheers,

JB.

Here's a simplified sequence of actions that appears to result in deadlock:

  1. import RDF snippet, graph containing single statement ex:1 rdfs:label "1"
  2. begin transaction
  3. execute cypher MATCH(m:Resource {{http://www.w3.org/2000/01/rdf-schema#label`:'1'}}) DETACH DELETE m
  4. import RDF snippet, graph containing single statement ex:1 rdfs:label "1"
  5. end transaction

The second import hangs. Based upon your comment, it appears that the node in question is locked and therefore the import is unable to complete, and consequently it results in deadlock.

I guess what I need is some way whereby the second import can be instructed to use an existing transaction as opposed to operating in the context of a second, conflicting, transaction.

(Obviously in real life one would probably post a different label value but this is just meant to illustrate the behavior)