CODEWITHSUNDEEP
node.jsdatabaseneo4jgraphenedb
Dana Woodman
Dana Woodman

Reputation: 4552

Neo4j "Can't wait on resource" lock error

I am using Node.js to connect to a hosted GrapheneDB Neo4j database and when attempting to add about 1,500 records I get the following error:

LockClient[19] can't wait on resource 
RWLock[NODE(248), hash=1917331445] since => LockClient[19] 
<-[:HELD_BY]- RWLock[INDEX_ENTRY(153122458561043471), hash=1171319680] 
<-[:WAITING_FOR]- LockClient[15] <-[:HELD_BY]- RWLock[NODE(248), hash=1917331445]

The code that generates this comes from a route that takes a list of JSON objects and then stores them in Neo4j. When importing approx 1,500 records I get this error consistently.

Using seraph-model to do the database accessing and just looking up the record, updating if it exists or creating it if it doesn't.

Any suggestions where to investigate?

Upvotes: 7

Views: 3988

Answers (2)

zakmck
zakmck

Reputation: 3024

I've been experiencing this too. Suggested workarounds I've read about are:

  • serialise parallel writings (but you lose the benefit of parallelism)
  • list nodes in the writing query using some order, e.g., sorting the IDs (but it adds the sorting overhead to the writing threads)

I've decided to go with the third option: re-attempt the Cypher operation until it goes well, or up to a max no. of times, pause for a random time between the attempts. This utility of mine can help. For the Neo4 driver, org.neo4j.driver.v1.exceptions.TransientException is the exception that you want to pass to the constructor.

Upvotes: 0

Stefan Armbruster
Stefan Armbruster

Reputation: 39925

It looks like you're doing multiple large transactions concurrently hitting the same region of your graph.

When Neo4j performs a write, a write lock is acquired on that node/relationship and released when the transactions is closed. Other transaction running concurrently who try to acquire a write lock on a already locked entity need to wait - otherwise a box of pandora's inconsistencies would have had opened. If the owner of the lock is a rather long running transaction, the other one might run into a timeout - that would be the above error message.

So you can either:

  1. serialize the operations: don't do writes in parallel, instead make sure only one fat transaction is processed at a given time
  2. make transactions smaller: if you do less in a singe transaction, the duration will be shorter and other transactions waiting for locks won't timeout.

Upvotes: 10

Related Questions