> Speaking of read operation, I will consider "Node.getProperties(String... names)" as a single read operation
It's a read operation per property name. You can read them all atomically if you grab a read lock on the node with "Transaction.acquireReadLock( node )". On Tue, Nov 27, 2018 at 5:18 AM sel-fish finch <dwyane.h...@gmail.com> wrote: > Thanks for your answer, Chris. > > Speaking of read operation, I will consider "Node.getProperties(String... > names)" as a single read operation. > So if I try to modify the value of two properties in a write transaction, > i expect the method 'getProperties' return both the old values or both the > new values. > Is that expectation right ? > > > 在 2018年11月26日星期一 UTC+8下午6:33:04，Chris Vest写道： >> >> 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 <dwyan...@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+un...@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. > -- 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.
