[
https://issues.apache.org/jira/browse/PHOENIX-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969069#comment-16969069
]
Hadoop QA commented on PHOENIX-5562:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12985149/PHOENIX-5562.master.001.patch
against master branch at commit ec78cd142a21a2ccf6f1f53ee16b501bf81352c5.
ATTACHMENT ID: 12985149
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3096//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3096//console
This message is automatically generated.
> The last concurrent update can complete the last write phase
> ------------------------------------------------------------
>
> 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
> Attachments: PHOENIX-5562.master.001.patch
>
> Time Spent: 10m
> 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. Although this behavior
> leads to the correct end result, ideally we would like to see that the
> concurrent update with most recent timestamp proceeds with the last phase
> instead of leaving the index rows in the unverified status. This would reduce
> the number of unverified rows due to concurrent updates.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
