Reputation: 757
I'm running a setup where I use a jdbc API installing neo4j-jdbc driver to connect to the neo4j database in VM, and I ran into a deadlock issue when doing some multi-thread works. I wonder if anyone knows if the neo4j-jdbc driver 3.x is thread safe or not?
Error Log
Exception: java.sql.BatchUpdateException: org.neo4j.driver.v1.exceptions.TransientException: LockClient[4211] can't wait on resource RWLock[NODE(2410), hash=1674994875] since => LockClient[4211] <-[:HELD_BY]- RWLock[NODE(2403), hash=1544505462] <-[:WAITING_FOR]- LockClient[4205] <-[:HELD_BY]- RWLock[NODE(2410), hash=1674994875]
org.neo4j.jdbc.bolt.BoltPreparedStatement.executeBatch(BoltPreparedStatement.java:178)
org.apache.commons.dbcp2.DelegatingStatement.executeBatch(DelegatingStatement.java:345)
org.apache.commons.dbcp2.DelegatingStatement.executeBatch(DelegatingStatement.java:345)
org.apache.beam.sdk.io.jdbc.JdbcIO$Write$WriteFn.finishBundle(JdbcIO.java:480)
Caused By: org.neo4j.driver.v1.exceptions.TransientException: LockClient[4211] can't wait on resource RWLock[NODE(2410), hash=1674994875] since => LockClient[4211] <-[:HELD_BY]- RWLock[NODE(2403), hash=1544505462] <-[:WAITING_FOR]- LockClient[4205] <-[:HELD_BY]- RWLock[NODE(2410), hash=1674994875]
org.neo4j.driver.internal.connector.socket.SocketResponseHandler.handleFailureMessage(SocketResponseHandler.java:71)
org.neo4j.driver.internal.messaging.PackStreamMessageFormatV1$Reader.unpackFailureMessage(PackStreamMessageFormatV1.java:464)
org.neo4j.driver.internal.messaging.PackStreamMessageFormatV1$Reader.read(PackStreamMessageFormatV1.java:425)
org.neo4j.driver.internal.connector.socket.SocketClient.receiveOne(SocketClient.java:130)
org.neo4j.driver.internal.connector.socket.SocketConnection.receiveOne(SocketConnection.java:143)
Stack trace truncated. Please see Cloud Logging for the entire trace.
Upvotes: 0
Views: 432
Reputation: 67044
The deadlock is a result of "normal" neo4j behavior in the presence of concurrent requests. You should be aware of neo4j's default locking behavior, and the documentation on deadlocks.
This may be the most helpful paragraph:
Experiencing frequent deadlocks is an indication of concurrent write requests happening in such a way that it is not possible to execute them while at the same time live up to the intended isolation and consistency. The solution is to make sure concurrent updates happen in a reasonable way. For example given two specific nodes (A and B), adding or deleting relationships to both these nodes in random order for each transaction will result in deadlocks when there are two or more transactions doing that concurrently. One solution is to make sure that updates always happens in the same order (first A then B). Another solution is to make sure that each thread/transaction does not have any conflicting writes to a node or relationship as some other concurrent transaction. This can for example be achieved by letting a single thread do all updates of a specific type.
Upvotes: 2