Re:How FoundationDB works and why it works
by zinodaur on Tuesday September 19, 2023 @10:16AM
(#37570285)
My understanding of ReadVersion is that the only point of calling it is to be able to read your own writes - so staleness wouldn't be good. There was another sibling comment that says the ReadVersion requests are batched up before hitting the sequencer, I could definitely believe that would work.
[ Parent
| on HN ]
Re:How FoundationDB works and why it works
by Dave_Rosenthal on Tuesday September 19, 2023 @05:18PM
(#37576856)
Yeah, read versions are just there to make what's known as "external consistency" work. That is, if transaction B starts after transaction A commits, then B will see the effects of A.
The reason external consistency is nice is that if you change the database, as soon as you get a commit signal, you can tell any other client "hey, go check the database and see what I did" and they will see the changes. No worries about whether the changes have sync'ed yet or anything like that.
Re:How FoundationDB works and why it works
by zinodaur on Thursday September 21, 2023 @11:53PM
(#37607631)
We've been exploring ways of getting external consistency for our data model - but our Sequencers are different enough that I don't think we can use the FoundationDB approach.
We are trying out a version of what CockroachDB does - run transaction A possibly on stale data, spy on the things it reads, call our flavor of ReadVersion for the "shards" the transaction interacted with, and re-run transaction A with the data versions we got from ReadVersion. It will usually just return after the the first run, rarely requiring a second run, and in some pathological cases require infinite runs.