Under specific scenarios a DeadlockDetectedException may be encountered and the behavior is described at https://neo4j.com/docs/java-reference/current/transaction-management/#transactions-deadlocks. When a DeadlockDetected is encountered one option is to simply retry the statement. As a deadlock detection error is a safe-to-retry error and the user is expected to handle these in all application code, since there may be legitimate deadlocks at any time, this behavior is actually by design to gain scalability. The following describes a scenario where a deadlock can be demonstrated/reproduced.

In the above scenario tx1001 is started at 08:00:01 and then @ 08:00:02 performs an update on the Person node for 'Tom Hanks' and defines age to be 59, resulting in a Write-Lock placed on this node.
tx1002 is then started at 08:00:03 and subsequently at 08:00:04 performs an update on the Movie node for Cast Away and defines the gross to be 233630478, resulting on a Write-Lock on this node.
tx1001 @ 08:00:05 then attempts to update the Movie node for Cast Away but is blocked as a result of the transaction @ 08:00:04 which has a Write-Lock on this node.
tx1002 @08:00:06 then attempts to update the Person node for Tom Hanks but is blocked as a result of the transaction at 08:00:02 which has a Write-Lock on this node.

Since the last two statements are waiting on each other, the dead lock is detected and the transaction at 08:00:06 is aborted with the following error