belliottsmith commented on PR #106: URL: https://github.com/apache/cassandra-accord/pull/106#issuecomment-2251561895
> inconsistent naming between connected concepts(ie the connection between Write witnessed txns, managed txnIds, and direct and key deps could be better illustrated through a term shared between them as well as an explanation) I agree this is an area that is under-documented. I will expand the class level documentation to explain the semantics here. I'm not sure there's a good shared name, but to briefly explain: CFK does two jobs today: 1) compute dependencies, for which it needs to track everything that might be witnessed (i.e. `manages`); 2) trigger local execution once dependencies have executed (i.e. `managesExecution`). The CFK only directly manages the execution of read and write transactions, essentially. The others listen to the CFK only to know when any read/write dependencies have executed. All other key transactions are managed as "direct" dependencies, via the old/range txn scheme of `NotifyWaitingOn` and tracking the `TxnId` directly in `WaitingOn`. This isn't actually different to before, except that we now separate out the `directKeyDeps` (those we must take direct dependencies on) and plain `keyDeps` (those we take a dependency on only the "Key" (i.e. we rely on CFK managed execution)). The reason we separate these out early on is because we do actually need to be able to filter these en masse using the Keydets class if and when we have shard-level redundancy information. This was to address an existing bug. The reason we can't easily let CFK manage the execution of these transactions is that EphemeralReads and ExclusiveSyncPoints don't actually have an execution time, so we would just build a similar kind of logic within CFK to be able to support them in CFK. SyncPoints on the other hand just complicate the execution logic because they aren't visible to Writes, and the efficiency of the approach taken today depends on knowing we won't execute anything behind the last applied write. This element could certainly be reworked in future, but it seemed rational to defer any further improvements there, and to lean on our existing logic. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
