Neo4j is Read Committed, which gives us a lot of freedoms that we can exploit to optimise performance. Being Read Committed means that transactions can observe newly committed data at any time. The most common way to think of this, is to imagine the read operations spread out on a time line, with a write set from newly committed write transactions intersecting at particular instants. This mental model assumes that writes are applied atomically, and reads are not. It is how this is most commonly explained in literature. However, you can also think of this as the reads intersecting an instant on a time line of write operations. These two models are isomorphic. In your example, it means that we can update the properties one at a time, and if you observe them being updated out of lock-step, we can tell you the write happened atomically in between your two reads. There is more going on to make this work well in practice; careful ordering of operations on the write side, and compensating actions on the read side, and also (very fast) page-level read/write latches to ensure record-level atomicity. This means that we can get away with very few read locks, while still being Read Committed. And in the vast majority of cases, Read Committed works out well for graphs. Neo4j uses Pessimistic Concurrency Control and 2 Phase Locking, so in the few cases where Read Committed is not enough, it is very easy to locally strengthen your isolation level by just taking more locks.
On Mon, Nov 26, 2018 at 4:54 AM sel-fish finch <dwyane.h...@gmail.com> wrote: > Asked this question in SO > <https://stackoverflow.com/questions/53331040/atomicity-of-recordstorageengine-in-neo4j>, > as i'm still struggling to get the answer through the code, I prefer to > try my luck here :) > > > Base on the source code of neo4j 3.2.3 > <https://github.com/neo4j/neo4j/releases/tag/3.2.3>, > TransactionRepresentationCommitProcess.commit will do the work to commit > transaction changes maintained in TxState. > > It contains two parts: append to transaction log; apply to store which is > RecordStorageEngine. > > That's a typical practice to commit a transaction. As in other storage > engine, we use mvcc or read lock to make sure the changes of transaction > happen atomically. > > My question is: > *How RecordStorageEngine ensure the atomicity of transaction?* > > To be precise, if one transaction modifies the values of two properties. > Will these two changes happen atomically? > > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to neo4j+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to neo4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
