I have some code that needs to acquire a write lock on a node. For various reasons it is inconvenient to use the Java API to acquire the lock, so I acquired it in Cypher 2.1 by setting a dummy value on the node. Then I use the node in a different query. In 2.1, calling SET n._lock = 1 was sufficient to acquire a write lock on the node for the rest of the transaction. However, when I upgrade to 2.2, I have a test that fails, because the write lock appears to be lost between queries within the same transaction. (I'm using Neo4j Community edition in embedded mode.)
So I have two queries like so (in the same TX):
MATCH (a:A)
WHERE ID(a) = {aId}
SET a._lock = 1
MATCH (a:A)
WHERE ID(a) = {aId}
WITH a
MATCH (b:B)-[:IS_AT]->(a:A)
... // then more application code in the same TX
I have a unit test that calls this code multiple times in parallel and verifies a mutex property of the later code, ie. the later code was not run in parallel due to the write lock in the first query (there is only one "A" node in the test). This test passes in 2.1, but fails in 2.2. If I modify the second query to be like
MATCH (a:A)
WHERE ID(a) = {aId}
SET a._lock = 1
WITH a
MATCH (b:B)-[:IS_AT]->(a:A)
...
The test passes. This seems to be evidence that the TX "loses" the write lock between the first and second query, which is disturbing. Can anyone explain this behavior?
