[
https://issues.apache.org/jira/browse/CASSANDRA-10082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14701637#comment-14701637
]
Blake Eggleston commented on CASSANDRA-10082:
---------------------------------------------
Sure, here you go:
https://github.com/apache/cassandra/compare/cassandra-2.2...bdeggleston:10082.
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: https://issues.apache.org/jira/browse/CASSANDRA-10082
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Blake Eggleston
> Assignee: Blake Eggleston
> Attachments:
> 0001-replacing-SequentialWriter-OutputStream-extension-wi.patch, 10082-2.txt
>
>
> 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
(v6.3.4#6332)
