[
https://issues.apache.org/jira/browse/PHOENIX-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated PHOENIX-7379:
----------------------------------
Fix Version/s: 5.3.0
> Improve handling of concurrent index mutations with the same timestamp
> ----------------------------------------------------------------------
>
> Key: PHOENIX-7379
> URL: https://issues.apache.org/jira/browse/PHOENIX-7379
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Kadir Ozdemir
> Assignee: Kadir Ozdemir
> Priority: Major
> Fix For: 5.3.0
>
>
> IndexRegionObserver after preparing the index updates just before releasing
> row locks for a given batch checks if the current millisecond is the same as
> the timestamp assigned for this batch. If so, its thread for this batch
> sleeps for 1 ms so that the next batch of updates does not get the same
> timestamp. Then, it releases the row locks.
> This is done to prevent having two different mutations with the same
> timestamp on the same row since the order of these mutations on the data
> table and index cannot be guaranteed to be same. If the order is not the
> same, then the data table and index will be inconsistent.
> One drawback of this approach is that if the index mutation preparation takes
> less than 1 ms, then the data table mutation latency increases by 1 ms. Index
> preparation takes more than 1 ms if IndexRegionObserver retrieves the current
> state of the data table row from disk. However, if the row is cached in
> memory, then the index preparation can easily take less than 1 ms. Also,
> IndexRegionObserver does not need to retrieve the current row state for
> uncovered indexes usually. For uncovered indexes, this logic almost always
> adds 1 ms to the mutation latency.
> We can improve this by not sleeping proactively instead sleeping only when a
> mutation on a row attempts to get the same timestamp of the previous mutation
> on the same row.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
