21–30 of 111 posts
I'd like to know how its model of transaction isolation works given that reads and writes are claimed to be independent. It seems as though a 'transaction' is defined as an atomic set of updates, but doesn't involve reads.
Any MVCC-style model allows full concurrency between readers and writers. The bigger problem is managing concurrency between conflicting writers in what amounts to a distributed database system. None of the material on Datomic's website explains how they intend to tackle that issue, which seems especially tricky with their model of distributed peers. All they say is that the Transactor is responsible for globally linearizing transactions and that this is better than existing models. However, if there is a genuine conflict, the loose coupling among peers seems to make the problem much worse than existing models, not better.
I'd love to know more details.
I'd like to know how its model of transaction isolation works given that reads and writes are claimed to be independent. It seems as though a 'transaction' is defined as an atomic set of updates, but doesn't involve reads.
> I'd like to know how its model of transaction isolation works given that reads and writes are claimed to be independent. Any MVCC-style model allows full concurrency between readers and writers. The bigger problem is managing concurrency between conflicting writers in what amounts to a distributed database system. None of the material on Datomic's website explains how they intend to tackle that issue, which seems e…
I'd like to know how its model of transaction isolation works given that reads and writes are claimed to be independent. It seems as though a 'transaction' is defined as an atomic set of updates, but doesn't involve reads.
> I'd like to know how its model of transaction isolation works given that reads and writes are claimed to be independent. Any MVCC-style model allows full concurrency between readers and writers. The bigger problem is managing concurrency between conflicting writers in what amounts to a distributed database system. None of the material on Datomic's website explains how they intend to tackle that issue, which seems e…
Earlier quoted context omitted.
> I'd like to know how its model of transaction isolation works given that reads and writes are claimed to be independent. Any MVCC-style model allows full concurrency between readers and writers. The bigger problem is managing concurrency between conflicting writers in what amounts to a distributed database system. None of the material on Datomic's website explains how they intend to tackle that issue, which seems e…
When data is immutable, append-only, and tagged by timestamp, there is no conflict. Rather, there are facts on the same entity that are asserted at different times. In this case where changes come in at two times (which are subject to all the raciness of the real world that exists regardless), one will win.
That describes many methods of optimistic concurrency control, but it doesn't answer my question of how this supposed to work in practice with high write contention, the higher latency of a distributed peer model, the long-running transactions the video mentions (or maybe that remark only applied to long-running queries), etc. My point being, if the distributed transaction problem was easily solved by sprinkling on optimistic multi-versioning concurrency control, it would have been solved a long time ago. There must be some special sauce they're not mentioning.
Webdevs will be all over this when the Peer runs on Javascript runtimes. Who's taking bets that it's written in Clojurescript?