[CASSANDRA-8984] Introduce Transactional API for behaviours that can corrupt system state

• Type: Improvement
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 2.2.0 rc1
• Assignee: Benedict Elliott Smith
• Reporter: Benedict Elliott Smith

Authors

Benedict Elliott Smith

Reviewers

Joshua McKenzie

• Created: 17/Mar/15 22:58
• Updated: 16/Apr/19 09:31
• Resolved: 17/May/15 21:25

Description

As a penultimate (and probably final for 2.1, if we agree to introduce it there) round of changes to the internals managing sstable writing, I've introduced a new API called "Transactional" that I hope will make it much easier to write correct behaviour. As things stand we conflate a lot of behaviours into methods like "close" - the recent changes unpicked some of these, but didn't go far enough. My proposal here introduces an interface designed to support four actions (on top of their normal function):

• prepareToCommit
• commit
• abort
• cleanup

In normal operation, once we have finished constructing a state change we call prepareToCommit; once all such state changes are prepared, we call commit. If at any point everything fails, abort is called. In either case, cleanup is called at the very last.

These transactional objects are all AutoCloseable, with the behaviour being to rollback any changes unless commit has completed successfully.

The changes are actually less invasive than it might sound, since we did recently introduce abort in some places, as well as have commit like methods. This simply formalises the behaviour, and makes it consistent between all objects that interact in this way. Much of the code change is boilerplate, such as moving an object into a try-declaration, although the change is still non-trivial. What it does do is eliminate a lot of special casing that we have had since 2.1 was released. The data tracker API changes and compaction leftover cleanups should finish the job with making this much easier to reason about, but this change I think is worthwhile considering for 2.1, since we've just overhauled this entire area (and not released these changes), and this change is essentially just the finishing touches, so the risk is minimal and the potential gains reasonably significant.

Issue Links

• is duplicated by: CASSANDRA-8690 Ensure all error handling code that may itself throw an exception utilises addSuppressed
• supercedes: CASSANDRA-9117 LEAK DETECTED during repair, startup