phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kadir OZDEMIR (Jira)" <j...@apache.org>
Subject [jira] [Created] (PHOENIX-5836) The first concurrent mutation may not be considered as concurrent
Date Mon, 13 Apr 2020 20:25:00 GMT
Kadir OZDEMIR created PHOENIX-5836:
--------------------------------------

             Summary: The first concurrent mutation may not be considered as concurrent
                 Key: PHOENIX-5836
                 URL: https://issues.apache.org/jira/browse/PHOENIX-5836
             Project: Phoenix
          Issue Type: Improvement
    Affects Versions: 4.14.3, 5.0.0
            Reporter: Kadir OZDEMIR
            Assignee: Kadir OZDEMIR


>From the consistent indexing design (PHOENIX-5156) perspective, two or more pending updates
from different batches on the same data row are concurrent if and only if for all of these
updates the data table row state is read from HBase under the row lock and for none of them
the row lock has been acquired the second time for updating the data table. In other words,
all of them are in the first update phase concurrently. For concurrent updates, the first
two update phases are done but the last update phase is skipped. 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.

However, if a concurrent mutation acquires the lock for reading the data row before any other
concurrent mutations on this mutation, and also acquires the lock for updating the data row
before any other mutations, this mutation can be treated as non-concurrent, and the third
update phase can be executed safely for this mutation. Doing this will reduce the number of
unverified rows due to concurrent mutations. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message