[
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)
