[
https://issues.apache.org/jira/browse/CASSANDRA-9832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14711011#comment-14711011
]
Sam Tunnicliffe commented on CASSANDRA-9832:
--------------------------------------------
It was initially deemed necessary as an early version of the new API would hold
a single OpOrder while processing an entire partition during compaction (&
cleanup). In the version which was ultimately committed however, each row
within a partition is updated as a distinct operation. So this would likely
still be of benefit to the indexing subsystem if/when we come to improve the
compaction & cleanup processing to batch row updates a bit more intelligently.
As it stands though this is no longer critical, at least not for secondary
indexing.
> OpOrder: BarrierJumpingOp
> -------------------------
>
> Key: CASSANDRA-9832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9832
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Priority: Minor
> Fix For: 3.0 beta 2
>
>
> Necessary for safe secondary index operation under the new API: a long
> running operation for use with OpOrder, that can jump between barriers at
> safe moments, without incurring the cost of starting/stopping except when
> necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
