phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kadir OZDEMIR (Jira)" <>
Subject [jira] [Created] (PHOENIX-5562) The last concurrent update can complete the last write phase
Date Thu, 07 Nov 2019 03:07:00 GMT
Kadir OZDEMIR created PHOENIX-5562:

             Summary: The last concurrent update can complete the last write phase
                 Key: PHOENIX-5562
             Project: Phoenix
          Issue Type: Improvement
    Affects Versions: 5.1.0
            Reporter: Kadir OZDEMIR
            Assignee: Kadir OZDEMIR

>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

In the current implementation, these updates can detect the existence of each other in two

(1) after acquiring the lock to read the existing row on the data table 

(1) 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

This message was sent by Atlassian Jira

View raw message