Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.
06-22-2020 01:52 PM
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?
06-29-2020 04:44 PM
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.
07-06-2020 04:29 PM
Here's a simplified sequence of actions that appears to result in deadlock:
ex:1 rdfs:label "1"
MATCH(m:Resource {{
http://www.w3.org/2000/01/rdf-schema#label`:'1'}}) DETACH DELETE mex:1 rdfs:label "1"
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)
All the sessions of the conference are now available online