[
https://issues.apache.org/jira/browse/CASSANDRA-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631066#comment-14631066
]
Stefania commented on CASSANDRA-7066:
-------------------------------------
bq. Also, I'd like to propose we hide TransactionLogs a little, by making its
class constructor package-private, and ensuring it only ever exists as part of
a LifecycleTransaction.
[~benedict], we can make it package private but I think there is one legitimate
case where we need the transaction logs without a lifecycle transaction and
that is when we only have a writer, like for {{SSTableTxnWriter}}. Do you think
we should extend the lifecycle transaction to handle the case of no existing
readers, no cfs but only one new writer? It seems kind of heavy to me and I
would prefer to just move SSTableTxnWriter to the lifecycle package, perhaps
with a better name? Also, the transaction logs must be created before the
writer, because it must register the new file in its constructor before
creating it.
> Simplify (and unify) cleanup of compaction leftovers
> ----------------------------------------------------
>
> Key: CASSANDRA-7066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7066
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Stefania
> Priority: Minor
> Labels: benedict-to-commit, compaction
> Fix For: 3.x
>
> Attachments: 7066.txt
>
>
> Currently we manage a list of in-progress compactions in a system table,
> which we use to cleanup incomplete compactions when we're done. The problem
> with this is that 1) it's a bit clunky (and leaves us in positions where we
> can unnecessarily cleanup completed files, or conversely not cleanup files
> that have been superceded); and 2) it's only used for a regular compaction -
> no other compaction types are guarded in the same way, so can result in
> duplication if we fail before deleting the replacements.
> I'd like to see each sstable store in its metadata its direct ancestors, and
> on startup we simply delete any sstables that occur in the union of all
> ancestor sets. This way as soon as we finish writing we're capable of
> cleaning up any leftovers, so we never get duplication. It's also much easier
> to reason about.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
