anchor.diff:  REMOVE n._LOCK_
   ----
   
  -The existence of the first `SET` before 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.
  +The existence of the first `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.
   
   [[transactions-locking]]
   == Default locking behavior ==
  
positive.code: ----
  
  This is because all queries will read the value of `n.prop` within their own transaction.
  They will not see the incremented value from other transactions.
  
  To ensure deterministic behavior, it is necessary to grab a write lock on the node in question.
  In Cypher there is no explicit support for this, but we can workaround this limitation by writing to a temporary property.
  
  [source,cypher]
  ----
  
negative.code: 
  === 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 will not result in a deterministic final value.
  
  For example, the following query, if run by one hundred concurrent clients, will very likely not increment the property `n.prop` to 100, but some value lower than 100.
  
  [source,cypher]
  ----
  