what does transaction mean in reference with neo4j database

Question

I got a bit confuse with term transaction. Suppose in transaction A we have two commands C1 and C2 and same in transaction B. Now both transaction come at same time then Are these observations correct?

1. All commands of transaction A C1 and C2 will be done first (assuming A enter first) , then only commands of transaction B will be executed.

2. Any command of transaction A or B can be executed but with assurance that If any of the command fails of any of the transaction then that transaction will be rollback.

3. If second case is true then in transaction by default, it do not lock any resource until its completion

4. If first case is true then by default transaction hold lock on resources until their completion.

thanks

Amit Aggarwal

Answer 1

We need to talk about the "I" in ACID (Neo4j is ACID-compliant), which stands for "isolation". The level of isolation tells you, how much of each other's data concurrently running transaction see.

The default isolation level in Neo4j is "read committed". This means A will not see the data B has written, until B commits. This is achieved by automatic locking, which works as follows:

Neo4j read-locks nodes and relationships when you read them (you can obtain many read locks), and write-locks nodes and relationships when you modify them. Read lock can't be obtained when there is a write lock, and write lock can't be obtained when there is another write lock. Locks are released when the transaction commits.

However, some anomalies can happen at this isolation level, one of which is called "lost update".

For illustration, let c be your counter value (I understand an atomic counter is what your ultimately after). Both transaction are incrementing the counter by 1.

c=0
Tx1 reads c=0 (read locks c)
Tx2 reads c=0 (read locks c)
Tx1 writes c=1 (write locks c)
Tx1 commits (unlocks c)
Tx2 writes c=1 (because it thinks c is still 0, write locks c)
Tx2 commits (unlocks c)

The update Tx1 has made is lost.

To prevent this, you need to change the isolation level to "repeatable read" by write-locking the objects you're going to modify explicitly up front, before reading their current value. This way, they will not be modifiable by any other concurrently running transaction.

c=0
Tx1 write locks c
Tx1 reads c=0 
Tx2 tries to write lock c, has to wait
Tx1 writes c=1
Tx1 commits (unlocks c)
Tx2 write locks c (because it now can)
Tx2 reads c=1 
Tx2 writes c=2 
Tx2 commits (unlocks c)

Hope that makes things clearer.