cassandra-commits mailing list archives

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


Blake Eggleston commented on CASSANDRA-10082:

Sure, here you go:
Note that the work is against 2.2, since CASSANDRA-10083 depends on it.

Thinking about this a bit more, do you think it would make more sense to reverse the approach?
Leave SequentialWriter as an OutputStream, but provide the methods needed for Transactional
users to use it as part of their commit/abort flow? SW seems like it has more in common with
OutputStream than SSTableWriter et al. That would be more involved though, and might be better
as a follow on ticket.

> 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