aweisberg commented on code in PR #4220: URL: https://github.com/apache/cassandra/pull/4220#discussion_r2240571935
########## doc/modules/cassandra/pages/architecture/cql-on-accord.adoc: ########## @@ -253,10 +253,24 @@ at each replica when `TxnWrite.apply` is called. `TxnUpdate` is also responsible for populating the update with the monotonic transactional hybrid logical clock for the execution time of -the transaction. This is used instead of the coordinator generated -timestamp for `SERIAL` and `TransactionStatement` writes. Non-SERIAL -writes use the coordinator or user supplied timestamp although this may -change in between the time of this writing and final release. +the transaction. During migration, normal CQL operations will use the +Accord timestamp once a range starts migration, but will fall back to +server timestamp when migrating away from Accord. For normal CQL operations, +`USING TIMESTAMP` is supported and will cause the data to use the user +timestamp instead of the Accord one, though this breaks linearizability +and should be avoided when possible. + +For BATCH operations, timestamp handling is more complex: if the batch +uses `USING TIMESTAMP`, the user timestamp will be used. If all mutations +in a BATCH use `USING TIMESTAMP`, the user timestamp will be used. If not +using `USING TIMESTAMP` and all partition keys are on Accord, the Accord +timestamp is used. If the BATCH has some partitions on Accord and others +not on Accord, the server timestamp will be used (unsafe for multi-table Review Comment: Instead of unsafe, not linearizable for the writes to Accord tables. ########## doc/modules/cassandra/pages/managing/operating/onboarding-to-accord.adoc: ########## @@ -279,14 +279,29 @@ Supported read consistency levels are `ONE`, `QUORUM`, `SERIAL`, and == non-SERIAL consistency -non-SERIAL operations are not linearizable even when executed on Accord -because Accord will continue to write data using the coordinator -generated timestamp not the transaction's timestamp. +non-SERIAL operations are linearizable by default when migrated to Accord, +but during migration they might not be linearizable due to timestamp handling +changes. During migration, normal CQL operations will use the Accord +timestamp once a range starts migration, but will fall back to server +timestamp when migrating away from Accord. + +Hints will use server timestamp and they only come into play during +migration as hints won't be generated when a range is on Accord. `USING TIMESTAMP` is allowed and the application of the operations will occur in a linearizable order, but from the perspective of a reader the merged result may not appear linearizable. +For BATCH operations, timestamp handling is more complex: +- If the batch uses `USING TIMESTAMP`, the user timestamp will be used +- If all mutations in a BATCH use `USING TIMESTAMP`, the user timestamp will be used +- If not using `USING TIMESTAMP` and all partition keys are on Accord, the Accord timestamp is used +- If the BATCH has some partitions on Accord and others not on Accord, the server timestamp will be used (unsafe for multi-table batches where one table is not migrating to Accord) Review Comment: Unsafe is a little non-specific. The writes to the Accord table will not be linearizable. ########## doc/modules/cassandra/pages/managing/operating/onboarding-to-accord.adoc: ########## @@ -279,14 +279,29 @@ Supported read consistency levels are `ONE`, `QUORUM`, `SERIAL`, and == non-SERIAL consistency -non-SERIAL operations are not linearizable even when executed on Accord -because Accord will continue to write data using the coordinator -generated timestamp not the transaction's timestamp. +non-SERIAL operations are linearizable by default when migrated to Accord, +but during migration they might not be linearizable due to timestamp handling +changes. During migration, normal CQL operations will use the Accord +timestamp once a range starts migration, but will fall back to server +timestamp when migrating away from Accord. + +Hints will use server timestamp and they only come into play during Review Comment: And batch log replay. Also might be worth explaining that if only Accord tables are used the batch will not be written to the batch log, but if it's a mix of Accord and non-Accord tables then the batch will be written to the batch log. -- 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: pr-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: pr-unsubscr...@cassandra.apache.org For additional commands, e-mail: pr-h...@cassandra.apache.org
