4 ms·
This is a very good answer. So if I understand you correctly (please correct if I do not), atomicity is handled on a per connection basis (writes cannot be dis
by Efrim-Lipkin 10y ago
This is a very good answer. So if I understand you correctly (please correct if I do not), atomicity is handled on a per connection basis (writes cannot be distrubted). And there may be high latency in distributing a transaction, but read consistency is guaranteed by timestamp (equivalent to versioning).
Is this correct?
EL
- Efrim-Lipkin 10y agoOkay, Last question because I'm in Asia and it's 7:30 and I am tired. (But yea, I'm a Midwestern computer scientist who just happens to be in Asia ;-) Question #2 -- Two, or Three, or More transactions occur simultaneously that want to change data D. each of these transactions send out transaction logs that contradict each other. What happens? EL
- freels 10y agoOne thing that makes this easier is that FaunaDB does not support session transactions, rather you must express your transaction logic as a single Fauna query, which is executed atomically. Transactions can still involve arbitrary keys, however. And yes, for reads, by default the coordinating node chooses a timestamp and uses that to query all involved data partitions. Each partition will respond with the requested data as of at that timestamp, or will delay responding until it has caught up. One nice thing about this approach is that any chosen timestamp is enough to provide a consistent snapshot view of the dataset at that time. This ends up being useful for bulk or incremental reads, where a longer running process needs a stable view of the dataset.
- ewrcoffee 10y agoWithout session transaction, how does the application performs transactional read modify write?