7

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?

Dana Woodman
  • 4,148
  • 1
  • 38
  • 35

2 Answers2

10

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.
Stefan Armbruster
  • 39,465
  • 6
  • 87
  • 97
  • Thanks Stefan! I will attempt to reduce the transaction to one fat transaction and if it works will mark as accepted! – Dana Woodman Sep 02 '16 at 18:29
  • can we increase the lock timeout? – user1870400 Jul 02 '19 at 02:50
  • https://neo4j.com/docs/operations-manual/current/reference/configuration-settings/#config_dbms.lock.acquisition.timeout A third option may be to increase the lock timeout, but I think should only be considered if you already checked both #1 and #2 – ndh103 Sep 21 '21 at 02:35
0

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.

zakmck
  • 2,715
  • 1
  • 37
  • 53