Transactions - Neo4j in Action - page 165

node or relationship where there is an explicit read lock will be blocked until the lock is
released or the transaction finishes.
7.2.3. Writing in a transaction and explicit write locks
As discussed previously, the current transaction will acquire individual write locks auto-
matically for you on each resource when you try to mutate it. These locks, however, do not
necessarily all get acquired at the same time. There may well be cases where your busi-
ness logic will need to modify a collection of nodes or relationships in a consistent way,
and you want to guarantee that no other transaction is able to modify them concurrently.
If your application requires such a high transaction isolation level, which is very similar
to the Serializable isolation level in RDMS, you can acquire write locks on a set of graph
resources explicitly at the beginning of a transaction, before you mutate the data. As usual,
those locks will be released automatically when the transaction completes.
In the following listing, you acquire write locks explicitly on two nodes to guarantee
they're updated collectively in a serializable fashion.
Listing 7.6. Acquiring write locks explicitly
try (Transaction tx = graphDatabaseService.beginTx()) {
Index<Node> nodeIndex = graphDatabaseService.index().forNodes("byName");
Node n1 = nodeIndex.get("name", "John").getSingle();
Node n2 = nodeIndex.get("name", "Bob").getSingle();
tx.acquireWriteLock(n1);
tx.acquireWriteLock(n2);
n1.setProperty("age", 35);
n2.setProperty("age", 37);
tx.success();
}
Again,indoingthisyouneedtobeverycarefulandweighconsistencyagainstperformance
and resource consumption.
7.2.4. The danger of deadlocks
Although the locking techniques discussed earlier allow you to manage isolation levels
flexibly, locks inevitably introduce the possibility for deadlocks to happen. Deadlocks are
asortof“chickenoregg”situationthatcanhappeniftwoormoretransactionsarecompet-