[
https://issues.apache.org/jira/browse/PHOENIX-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16130951#comment-16130951
]
Thomas D'Silva commented on PHOENIX-4089:
-----------------------------------------
[~jamestaylor]
In MutationState.validate we no longer set the timestamp to table timestamp,
it is set to the scn or LATEST_TIMESTAMP, so do we still need the
Indexer.isProbablyClientControlledTimeStamp method?
{code}
- return scn == null ? serverTimeStamp == QueryConstants.UNSET_TIMESTAMP
? HConstants.LATEST_TIMESTAMP : serverTimeStamp : scn;
+ return scn == null ? HConstants.LATEST_TIMESTAMP : scn;
{code}
Also will UPSERT SELECT to the same table work correctly with this change? I
think we discussed something similar in PHOENIX-4051.
> Prevent index from getting out of sync with data table under high concurrency
> -----------------------------------------------------------------------------
>
> Key: PHOENIX-4089
> URL: https://issues.apache.org/jira/browse/PHOENIX-4089
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: James Taylor
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4089_4.x-HBase-0.98.patch,
> PHOENIX-4089_4.x-HBase-0.98_v2.patch, PHOENIX-4089_v1.patch,
> PHOENIX_4089_v2.patch, PHOENIX_4089_v3.patch, PHOENIX-4089_v4.patch
>
>
> Under high concurrency, we're still seeing the index get out of sync with the
> data table. It seems that the particular case is when the same Put occurs
> with the same time stamp from different clients, based on the locking we do,
> Phoenix thinks a different Put was the last one than HBase does, leading to
> inconsistencies.
> The solution is to timestamp the cells on the server-side after the lock has
> been taken. The new concurrent unit test passes 50x with this in place, while
> it otherwise fails 1/10 of the time (or more on HBase 1.3).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
