On Tue, Sep 7, 2021 at 1:31 AM bened...@apache.org <bened...@apache.org> wrote:
> > Of course, but we may have to be selective in our back-and-forth. We can > always take some discussion off-list to keep it manageable. > > I'll try to converge.Sorry if a few comments were a bit "editorial" in the first message. I find that sometimes it pays off to also ask the dumb questions, as long as we don't get stuck on any of them. > > The algorithm is hard to read since you omit the roles of the > participants. > > Thanks. I will consider how I might make it clearer that the portions of > the algorithm that execute on receipt of messages that may only be received > by replicas, are indeed executed by those replicas. > > In fact the same algorithm in the CEP was easier to read exactly because of this, I now realize. > > So I guess my question is how and when reads happen? > > I think this is reasonably well specified in the protocol and, since it’s > unclear what you’ve found confusing, I don’t know it would be productive to > try to explain it again here on list. You can look at the prototype, if > Java is easier for you to parse, as it is of course fully specified there > with no ambiguity. Or we can discuss off list, or perhaps on the community > slack channel. > > Maybe my question was a bit too open ended, as I didn't want to lead into any specific direction. I can of course tell where reads happen in the execution algorithm. What I would like to understand better and without guessing is, what do these transactions look like from a client/user point of view? You already confirmed that interactive transactions aren't intended by this proposal. At the other end of the spectrum, given that this is a Cassandra Enhancement Proposal, and the CEP does in fact state this, it seems like providing equivalent functionality to already existing LWT is a goal. So my question is whether I should just* think of this as "better and more efficient LWT" or is there something more? Would this CEP or follow-up work introduce any new CQL syntax, for example? To give just one more example of the kind of questions I'm triangulating at: Suppose I wanted to do a long running read-only transaction, such as querying a secondary index. Like SERIAL in current Cassandra, but taking seconds to execute and returning thousands of rows. How would you see the possibilities and limits of such operations in Accord? *) Should emphasize that better scaling LWTs isn't just "just". If I imagine a future Cassandra cluster where all reads and writes are transactional and therefore strict serializeable, that would be quite a change from today. henrik
