On Wed, Oct 13, 2021 at 3:38 PM bened...@apache.org <bened...@apache.org> wrote:
> It may have been lost in the back and forth (there’s been a lot of > emails), but I outlined an approach for READ COMMITTED (and SERIALIZABLE) > read isolation that does not require a WAN trip. Yes, thank you. I knew I had read it but was looking for this in the CEP/paper itself and couldn't find it when searching. Thanks for re-explaining here. However, for any multi-shard protocol it is unsafe to perform an > uncoordinated read as each shard may have applied different transaction > state – the timestamp you pick may be in the future on some shards. > > Ok, fair enough. Ah, I realize now we're talking past each other. What I had in mind I did not even expect that different rows or partitions need to reflect the same snapshot/timestamp. Just that each row independently reflects some state that was committed. "Per row read committed", if you will. I realize now that a) that requirement is probably trivially true for any read to any node managed by Accord, and b) maybe it's not appropriate to call this read committed after all. I agree that the spirit of read committed requires that if 2 rows were modified by the same transaction, then a future read including both rows, must show a consistent result of both the rows. > For my purposes I'll just note that needing to re-execute all reads > during the Accord phase (commit phase) would make the design more expensive > > I realize now my response that this was part of incorporates the same flawed thinking about "per row read commit" isolation. Thanks for persisting in educating me. > As noted by Alex, the only thing that needs to be corroborated in this > approach is the timestamps. However, this is only necessary for > SERIALIZABLE isolation or above. For READ COMMITTED it would be enough to > perform reads with the above properties, and to buffer writes until a final > Accord transaction round. However, as also noted by Alex, the difficulty > here is read-your-writes. This is a general problem for interactive > transactions and – like many of these properties - orthogonal to Accord. A > simple approach would be to nominate a coordinator for the transaction that > buffers writes and integrates them into the transaction execution. This > might impose some restrictions on the size of the transaction we want to > support, and of course means if the coordinator fails the transaction also > fails. > But that is true for Cassandra today as well. (For a shorter time window, anyway.) > > If we want to remove all restrictions, we are back at the monoculture of > Cockroach, YugaByte et al. Which, again, may both be implemented by, and > co-exist with, Accord. > > In this world, complex transactions would insert read and write intents > using an Accord operation, along with a transaction state record. If > transactions insert conflicting intents, the concurrency control > arbitration mechanism decides what happens (whether one transaction blocks, > aborts, or what have you). There is a bunch of literature on this that is > orthogonal to the Accord discussion. > > In the case of READ COMMITTED, I believe this can be particularly simple – > we don’t need any read intents, only write intents which are essentially a > distributed write buffer. The storage system uses these to answer reads > from the transaction that inserted the write intents, but they are ignored > for all other transactions. In this case, there is no arbitration needed as > there is never a need for one transaction to prevent another’s progress. A > final Accord operation commits these write intents atomically across all > shards, so that reads that occur after this operation integrate these > writes, and those that executed before do not. > > Note that in this world, one-shot transactions may still execute without > participating in the complex transaction system. In the READ COMMITTED > world this is particularly simple, they may simply execute immediately > using normal Accord operations. But it remains true even for SERIALIZABLE > isolation, so long as there are no read or write intents to these keys. In > this case we must validate there are no such intents, and if any are found > we may need to upgrade to a complex transaction. This can be done > atomically as part of the Accord operation, and then the transaction > concurrency control arbitration mechanism kicks in. > And now I teased you to outline a different read committed transaction approach :-) henrik -- Henrik Ingo +358 40 569 7354 <358405697354> [image: Visit us online.] <https://www.datastax.com/> [image: Visit us on Twitter.] <https://twitter.com/DataStaxEng> [image: Visit us on YouTube.] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_channel_UCqA6zOSMpQ55vvguq4Y0jAg&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=bmIfaie9O3fWJAu6lESvWj3HajV4VFwgwgVuKmxKZmE&s=16sY48_kvIb7sRQORknZrr3V8iLTfemFKbMVNZhdwgw&e=> [image: Visit my LinkedIn profile.] <https://www.linkedin.com/in/heingo/>
