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 > <javascript:>> 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 <javascript:>. >> 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.
