[
https://issues.apache.org/jira/browse/CASSANDRA-17104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-17104:
----------------------------------------
Test and Documentation Plan:
[cassandra|https://github.com/bdeggleston/cassandra/tree/metadata-persistence]
[accord|https://github.com/bdeggleston/cassandra-accord/tree/metadata-persistence]
was:
[cassandra|https://github.com/bdeggleston/cassandra/tree/metadata-persistence]
[accord|https://github.com/bdeggleston/cassandra-accord/tree/metadata-persistence]
A few points that could use some further discussion:
* TxnOperation was added to inform C* which commands/commands for key to load,
since optimizations are implementation specific, maybe we should get rid of
this and put the burden of working out what to load on cassandra?
* Since some accord requests block on operations sent to the mutation/read
stages, we can’t have those processing accord messages. I’ve added an accord
stage, but making accord requests async wouldn’t be a bad thing.
* There are some optimizations for commands for key that aren’t in memory.
However, they can’t be used since we always need the related commands per key
in memory. This is because almost all (or maybe all) messages may need to call
witness, with uses related cfks to calculate the executeAt time. If we had a
witness method which didn’t do this, and a preaccept method that did, we could
only require cfks be loaded for preaccept, accept, and probably recover
messages. I haven’t spent any time thinking about that being feasible though.
Requiring cfks be in memory to calculate database timestamps probably means
we’re always going to have to load them though
> CEP-15: (C*/Accord) Transaction state storage
> ---------------------------------------------
>
> Key: CASSANDRA-17104
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17104
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord
> Reporter: Benedict Elliott Smith
> Assignee: Blake Eggleston
> Priority: Normal
>
> This work encompasses persistent storage of Accord’s transaction state within
> Cassandra, including integration with the Commit Log, perhaps the use of
> SSTables or system tables, and in memory caches. This will entail refactors
> to Accord to support this.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
