[
https://issues.apache.org/jira/browse/PHOENIX-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17204349#comment-17204349
]
ASF GitHub Bot commented on PHOENIX-6160:
-----------------------------------------
kadirozde commented on a change in pull request #897:
URL: https://github.com/apache/phoenix/pull/897#discussion_r497110937
##########
File path:
phoenix-core/src/main/java/org/apache/phoenix/hbase/index/IndexRegionObserver.java
##########
@@ -150,9 +154,14 @@ public static void
setFailDataTableUpdatesForTesting(boolean fail) {
failDataTableUpdatesForTesting = fail;
}
+ public enum BatchMutatePhase {
+ PRE, POST, FAILED
+ }
// Hack to get around not being able to save any state between
// coprocessor calls. TODO: remove after HBASE-18127 when available
+
private static class BatchMutateContext {
+ private BatchMutatePhase currentPhase = BatchMutatePhase.PRE;
Review comment:
Great question! The concurrent batch of mutations is a set such that
every pair of batches in this set has at least one common row. Since a
BatchMutateContext object of a batch is modified only after the row locks for
all the rows that are mutated by this batch are acquired, there can be only one
thread can acquire the locks for its batch and safely access all the batch
contexts in the set of concurrent batches. I will add this to doc and comment
it on the code. Please note that the row state is also accessed. So, atomic
variables are not necessary. Also, making currentPhase atomic and leaving the
rest as it is will give a wrong impression.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Simplifying concurrent mutation handling for global Indexes
> -----------------------------------------------------------
>
> Key: PHOENIX-6160
> URL: https://issues.apache.org/jira/browse/PHOENIX-6160
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 5.0.0, 4.15.0
> Reporter: Kadir OZDEMIR
> Assignee: Kadir OZDEMIR
> Priority: Major
> Attachments: PHOENIX-6160.4.x.001.patch
>
>
> Please see the attached design document for the proposed simplification. The
> proposed design is simpler to understand and does not require a special
> handling of partial concurrent updates without indexed columns.
> One of the desired features for global indexes is to support atomic
> operations (ON_DUPLICATE_KEY statements). We have found that it is quite
> difficult to build such a feature on the current design as we need to add
> more case handling to the current design to handle data table update ordering
> issues. The proposed design does not require us to do changes on concurrent
> mutation handling for such features.
> The proposed design almost eliminates unverified index rows due to concurrent
> mutations. The index rows are left unverified only when batches fail to
> complete the data table updates. This leads to read performance improvement
> as repairing unverified rows is costly and each row repair adds several tens
> of milliseconds to the overall scan latency.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
