Database Reference
In-Depth Information
ing to acquire the locks on the same graph resources. If transaction A tries to lock nodes 1
and 2 in that order, while transaction B tries to acquire the locks for the same nodes in the
reverse order, then potentially each transaction could lock one node and wait indefinitely
for the other node to be released, thus creating a deadlock.
Neo4j has a built-in mechanism to detect deadlocks when they happen, in which case
a
DeadlockDetectedException
will be thrown and the transaction will be rolled
back. Deadlock detection is only possible when locking is exclusively managed by Neo4j;
that is, by relying on Neo4j's automatic default locking mechanism, or by only using the
Neo4j API locking-related methods (
acquireReadLock
and
acquireWriteLock
)
that we discussed previously. If any other locking mechanism is used, such as using the
Java
synchronized
keyword, deadlocks won't be detected if they happen, and your ap-
plication is likely to appear to hang.
To deal with deadlocks effectively, there are a number of simple things you can do. The
firstistosticktothecoreAPIprovidedbyNeo4jandnottouseanyexternallockingmech-
anism. This will ensure Neo4j's deadlock-detection mechanism will kick in, ensuring your
application doesn'tcompletely lockup,andthatdatawillremainconsistent. Alloperations
in the core Neo4j API (unless otherwise specified) are thread-safe, so you should gener-
ally have no need for external synchronization. The other simple thing you can do is avoid
deadlocks altogether by making sure that graph resources are consistently accessed in the
same order.
We've now covered Neo4j transactions in detail. In the next sections, we'll focus on issues
related to integrating Neo4j transactions with other transaction management systems.
7.3. Integration with other transaction management systems
The transaction-handling code we've looked at so far has exclusively used Neo4j's core
API to initiate and complete transactions; it didn't make any assumptions about the nature
of the environment that the code is executed from.
If you're building a typical enterprise application, though, it's likely that you'll need to in-
tegrate with an existing transaction manager, such as a JTA transaction manager provided
by the application server. The
org.neo4j.kernel.impl.transaction
package
contains a number of classes to support this use case.
