[ https://issues.apache.org/jira/browse/PHOENIX-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kadir OZDEMIR resolved PHOENIX-5836. ------------------------------------ Resolution: Incomplete > 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: 5.0.0, 4.14.3 > Reporter: Kadir OZDEMIR > Assignee: Kadir OZDEMIR > Priority: Major > Attachments: PHOENIX-5836.4.x.001.patch > > > 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)