[
https://issues.apache.org/jira/browse/CASSANDRA-8568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363327#comment-14363327
]
Benedict commented on CASSANDRA-8568:
-------------------------------------
Doubtful. For one we only really see problems once deployed to the wild, so
that won't likely help us until 3.0 is being widely used. But afaict the
problems we're seeing are mostly down to either:
# fiddliness of the current abstraction (lots of different methods that need to
be interleaved in non-obvious ways), so this patch will either fix them and so
give us no information, or have a different fix for the problem (and different
set of problems, and in either case not help us safely reason about the old
way); or
# problematic rollback of changes - which really involves backporting this
whole patch to address
The current code has been predicated on the assumption there are no problems,
and it's reached a level of complexity where that is an unsafe assumption, and
it cannot safely handle when this assumption is broken. As a result of #2 we
cannot safely fault injection test, because it cannot safely deal with
arbitrary failures (at best it copes with system failures, but not programming
failures - in fact the assertions dotted around the code at the moment
ironically make it more brittle than less).
> Impose new API on data tracker modifications that makes correct usage obvious
> and imposes safety
> ------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-8568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8568
> Project: Cassandra
> Issue Type: Bug
> Reporter: Benedict
> Assignee: Benedict
>
> DataTracker has become a bit of a quagmire, and not at all obvious to
> interface with, with many subtly different modifiers. I suspect it is still
> subtly broken, especially around error recovery.
> I propose piggy-backing on CASSANDRA-7705 to offer RAII (and GC-enforced, for
> those situations where a try/finally block isn't possible) objects that have
> transactional behaviour, and with few simple declarative methods that can be
> composed simply to provide all of the functionality we currently need.
> See CASSANDRA-8399 for context
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)