cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10082) Transactional classes shouldn't also implement streams, channels, etc
Date Tue, 18 Aug 2015 17:30:48 GMT


Benedict commented on CASSANDRA-10082:

bq. That would be more involved though, and might be better as a follow on ticket.

Right. I agree in principle, but I'd rather wait until 3.X and take a more overarching view
of this set of classes. Try and finish the sanitisation that [~stefania] has mostly been spearheading.
There's a lot of ugliness, and I'd rather try and make a final push to flush it all out. In
the process of cleaning it up we can hopefully separate out the transactional behaviour.

LGTM. Could you provide a patch against 3.0 as well, since it has been changed here?

> Transactional classes shouldn't also implement streams, channels, etc
> ---------------------------------------------------------------------
>                 Key: CASSANDRA-10082
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Blake Eggleston
>            Assignee: Blake Eggleston
>         Attachments: 0001-replacing-SequentialWriter-OutputStream-extension-wi.patch,
> Since the close method on the Transactional interface means "abort if commit hasn't been
called", mixing Transactional and AutoCloseable interfaces where close means "we're done here"
is pretty much never the right thing to do. 
> The only class that does this is SequentialWriter. It's not used in a way that causes
a problem, but it's still a potential hazard for future development.
> The attached patch replaces the SequentialWriter OutputStream implementation with a wrapper
class that implements the expected behavior on close, and adds a warning to the Transactional
interface. It also adds a unit test that demonstrates the problem without the fix.

This message was sent by Atlassian JIRA

View raw message