[
https://issues.apache.org/jira/browse/CASSANDRA-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384241#comment-14384241
]
Joshua McKenzie commented on CASSANDRA-8984:
--------------------------------------------
Now that we're pushing this back to 3.x, I think there's some value in
re-visiting the design to see if there's some opportunities for simplification.
bq. My hope is that these extra classes confer no complexity cost after
acclimation
While the initial complexity cost will be higher, even after acclimation the
more interacting objects and abstractions around behavior we have, the more the
complexity burden. This patch is enforcing a specific state-transition flow and
interface on 5 of 6 classes that are no-oping some or all of the interface
members which unnecessarily complicates their implementations for the sake of
codifying the try/catch/abort idiom.
bq. all about trying to make semantics clear and well defined
The amount of copy-pasted boilerplate and no-op state transitions in this patch
indicates to me there's some immediate opportunities for improvement. Also,
having to manage some state transitions manually leaks that portion of the
Transactional abstraction into the various overridden methods.
I haven't had the time to sit down and really consider revisions to this
design; there's the distinct possibility that after taking some time to really
consider the problem I'll come around to the same conclusions you have with
this, but since we have a bit of time now to let this soak and perhaps simplify
it I think we should take it.
bq. I marked CASSANDRA-8690 as a duplicate of this, but in reality it was
smaller in scope and might deliver a lot of the safety necessary.
What's your confidence regarding the likelihood of 8690 delivering on that
safety?
> Introduce Transactional API for behaviours that can corrupt system state
> ------------------------------------------------------------------------
>
> Key: CASSANDRA-8984
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8984
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Fix For: 2.1.4
>
> Attachments: 8984_windows_timeout.txt
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
