Transactions in Neo4j use a read-committed isolation level, which means they will see data as soon as it has been committed and will not see data in other transactions that have not yet been committed. This type of isolation is weaker than serialization but offers significant performance advantages whilst being sufficient for the overwhelming majority of cases.
In addition, the Neo4j Java API (see Advanced Usage) enables explicit locking of nodes and relationships. Using locks gives the opportunity to simulate the effects of higher levels of isolation by obtaining and releasing locks explicitly. For example, if a write lock is taken on a common node or relationship, then all transactions will serialize on that lock — giving the effect of a serialization isolation level.
Lost Updates in Cypher
In Cypher it is possible to acquire write locks to simulate improved isolation in some cases.
Consider the case where multiple concurrent Cypher queries increment the value of a property.
Due to the limitations of the read-committed isolation level, the increments might not result in a deterministic final value.
If there is a direct dependency, Cypher will automatically acquire a write lock before reading.
A direct dependency is when the right-hand side of a SET has a dependent property read in the expression, or in the value of a key-value pair in a literal map.
For example, the following query, if run by one hundred concurrent clients, will very likely not increment the property n.prop to 100, unless a write lock is acquired before reading the property value.
This is because all queries would read the value of n.prop within their own transaction, and would not see the incremented value from any other transaction that has not yet committed.
In the worst case scenario the final value would be as low as 1, if all threads perform the read before any has committed their transaction.
Requires a write lock, and Cypher automatically acquires one.
MATCH (n:X {id: 42})
SET n.prop = n.prop + 1
Also requires a write lock, and Cypher automatically acquires one.
MATCH (n)
SET n += { prop: n.prop + 1 }
Due to the complexity of determining such a dependency in the general case, Cypher does not cover any of the below example cases:
Variable depending on results from reading the property in an earlier statement.
MATCH (n) WITH n.prop as p // ... operations depending on p, producing k SET n.prop = k + 1
Circular dependency between properties read and written in the same query.
MATCH (n)
SET n += { propA: n.propB + 1, propB: n.propA + 1 }
To ensure deterministic behavior also in the more complex cases, it is necessary to explicitly acquire a write lock on the node in question. In Cypher there is no explicit support for this, but it is possible to work around this limitation by writing to a temporary property.
Acquires a write lock for the node by writing to a dummy property before reading the requested value.
MATCH (n:X {id: 42})
SET n._LOCK_ = true
WITH n.prop as p
// ... operations depending on p, producing k
SET n.prop = k + 1
REMOVE n._LOCK_
The existence of the SET n._LOCK_ statement before the read of the n.prop read ensures the lock is acquired before the read action, and no updates will be lost due to enforced serialization of all concurrent queries on that specific node.