Transactions - Neo4j in Action - page 161

This default behavior is very similar to the Read Committed isolation level in relational
databases, which removes the potential for dirty reads, but still allows phantom reads and
non-repeatable reads to happen.
What exactly is locked?
Which graph resources are locked and when? When you try to modify a graph object (that
is, when you create, delete, or update a property on a node or a relationship), Neo4j has to
acquire a write lock on the object in question to protect it against concurrent modification.
Equally, when you create a new relationship between two existing nodes, both nodes are
locked by the transaction.
A phantom read is the situation in which one transaction can potentially see a different
number of nodes and relationships at different times if some entities were added or deleted
by another transaction in the meantime.
In non-repeatable reads , a transaction can read the same property of a node or relationship
twiceandgetdifferentvaluesifthatpropertywasupdatedsimultaneouslybyanothertrans-
action.
Figure 7.1 illustratesthedefaultisolationlevelinNeo4j.Inthefigure,twothreadsarecom-
peting to access the same graph resources, resulting in a Read Committed isolation level.
It's possible to achieve higher transactional guarantees by managing locks explicitly, as
you'll see in the next section.
Transactions in High Availability mode
Thetransactionalbehaviordescribedinthischapterfocusesmainlyonwhathappenswithin
a single instance of Neo4j. In High Availability (HA) mode, there are two types of Neo4j
instances, master and slaves, and transactions ensure that writes are always consistent and
durable. Although technically you can target any Neo4j instance for a write operation,
writes are first pushed to the master and are eventually propagated to slaves. This behavi-
or is automatic and can be configured to achieve a suitable trade-off between performance
and durability. For more details on Neo4j HA and its use in production, see chapter 11 .