[
https://issues.apache.org/jira/browse/PHOENIX-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969582#comment-16969582
]
Hudson commented on PHOENIX-5562:
---------------------------------
SUCCESS: Integrated in Jenkins build Phoenix-4.x-HBase-1.5 #188 (See
[https://builds.apache.org/job/Phoenix-4.x-HBase-1.5/188/])
PHOENIX-5562 Simplify detection of concurrent updates on data tables (kadir:
rev 42ffee3792ea675379c5fb80339a6f3313469ac7)
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/hbase/index/IndexRegionObserver.java
> Simplify detection of concurrent updates on data tables with indexes
> --------------------------------------------------------------------
>
> Key: PHOENIX-5562
> URL: https://issues.apache.org/jira/browse/PHOENIX-5562
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 5.1.0
> Reporter: Kadir OZDEMIR
> Assignee: Kadir OZDEMIR
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> From the consistent secondary indexing design (PHOENIX-5156) perspective, two
> or more updates on the same row are concurrent updates if and only if all of
> them have acquired the row lock for reading the data table row before any of
> of them acquires the row lock the second time for updating the data table. In
> other words, all of them are in the first update phase concurrently.
> In the current implementation, these updates can detect the existence of each
> other in two places
> (1) after acquiring the lock to read the existing row on the data table
> (2) after acquiring the row lock to update the data table
> This allows all the concurrent updates to detect each other and complete
> first two update phases but skip the last update phase. This means the data
> table row will be updated by these updates but the corresponding index table
> rows will be left with the unverified status. Then, the read repair process
> will repair these unverified index rows during scans.
> The detection of concurrent updates can be simplified and done one in one
> place, i.e., after acquiring the row lock to update the data table.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
