LockClient can't wait on resource RWLock

753 views
Skip to first unread message

Ray Chengr

unread,
Sep 1, 2016, 9:00:33 PM9/1/16
to Neo4j
We're using Python 3.4.3, py2neo 2.0.8, Neo4j 3.0.3, on a 12 x 2.6GHz 96GB RAM box. Our relationship & node insertion rate is about 100+ per second. From time to time I saw this kind of error on neo4j.log. Is there anything we can do such as from neo4j.com to avoid this kind of error?

ERROR Failed to commit transaction. LockClient[5498051] can't wait on resource RWLock[RELATIONSHIP(2009573), hash=942147114] since => LockClient[5498051] <-[:HELD_BY]- RWLock[RELATIONSHIP(2009572), hash=1901714492] <-[:WAITING_FOR]- LockClient[5498052] <-[:HELD_BY]- RWLock[RELATIONSHIP(2009573), hash=942147114]
org.neo4j.kernel.DeadlockDetectedException: LockClient[5498051] can't wait on resource RWLock[RELATIONSHIP(2009573), hash=942147114] since => LockClient[5498051] <-[:HELD_BY]- RWLock[RELATIONSHIP(2009572), hash=1901714492] <-[:WAITING_FOR]- LockClient[5498052] <-[:HELD_BY]- RWLock[RELATIONSHIP(2009573), hash=942147114]
        at org.neo4j.kernel.impl.locking.community.RagManager.checkWaitOnRecursive(RagManager.java:198)
        at org.neo4j.kernel.impl.locking.community.RagManager.checkWaitOnRecursive(RagManager.java:225)
        at org.neo4j.kernel.impl.locking.community.RagManager.checkWaitOn(RagManager.java:165)
        at org.neo4j.kernel.impl.locking.community.RWLock.acquireWriteLock(RWLock.java:375)
        at org.neo4j.kernel.impl.locking.community.LockManagerImpl.getWriteLock(LockManagerImpl.java:55)
        at org.neo4j.kernel.impl.locking.community.CommunityLockClient.acquireExclusive(CommunityLockClient.java:142)
        at org.neo4j.kernel.impl.transaction.state.RelationshipCreator.connect(RelationshipCreator.java:202)

Thanks,
Ray

Michael Hunger

unread,
Sep 2, 2016, 5:40:56 AM9/2/16
to ne...@googlegroups.com, Dana Canzano
The reason is:

for creating/deleting a relationship both end-nodes are locked

and if you have one thread locking a, then trying b
while another does b, then tries a, none can proceed and one of the transactions will be killed with a deadlock exception.

Update to 3.0.4

recommended is to retry the query

otherwise:

* you can try to lock on a well known lock node to serialize that kind of access, you can either lock via removing a non-existing property, .e.g. REMOVE rootNode.__lock__ or with APOC's lock procedures
* sort, group, batch your updates so that you always update one subgraph in one tx so that there are no conflicting updates in two different transactions.

Michael

--
You received this message because you are subscribed to the Google Groups "Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email to neo4j+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages