[
https://issues.apache.org/jira/browse/CASSANDRA-20588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-20588:
------------------------------------------
Fix Version/s: 6.0-alpha2
(was: 6.0-alpha)
> Fix single token batch atomicity with Accord/non-Accord batches by using the
> batch log
> --------------------------------------------------------------------------------------
>
> Key: CASSANDRA-20588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20588
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Accord
> Reporter: Ariel Weisberg
> Assignee: Alan Wang
> Priority: Normal
> Fix For: 6.0-alpha2
>
> Attachments:
> ci_summary-cassandra-6.0-d334ce4a0ee2115bc0f4b9f4df93e754ecfb5e95.html,
> ci_summary.html,
> result_details-cassandra-6.0-d334ce4a0ee2115bc0f4b9f4df93e754ecfb5e95.tar.gz,
> result_details.tar.gz
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Single token batches are currently 99% atomic without Accord because they are
> sent to a single node and can be applied to multiple tables out of the commit
> log reliably. Currently if that happens and one table is running on Accord
> and one is not then the batch will be split it into a Cassandra write and an
> Accord write and lose atomicity.
> The most straightforward fix is probably to route the entire batch through
> Accord if any of it touches an Accord table. It’s fine to use Accord to apply
> writes and this won’t impact the latency since Accord was being used anyways.
> This will require some modifications to TxnUpdate and maybe TxnWrite to allow
> the entire contents of the batch even for tables Accord isn’t managing to tag
> along and be applied at the same time as the involved Accord tables.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
