[
https://issues.apache.org/jira/browse/PHOENIX-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131256#comment-16131256
]
James Taylor commented on PHOENIX-4089:
---------------------------------------
[~tdsilva]
We still need Indexer.isProbablyClientControlledTimeStamp method because tests
are still relying on being able to use CURRENT_SCN for DML. I've filed
PHOENIX-4096 to change that.
For UPSERT SELECT, since we keep the scanner open that's doing the SELECT, it
won't see new rows from the UPSERT. For example, the
UpsertSelectAutoCommitIT.testUpsertSelectDoesntSeeUpsertedData passes fine with
this change. One potential caveat is if the region splits while the UPSERT
SELECT is running. I believe that fails today (see PHOENIX-3163 and
PHOENIX-2903), but I've filed PHOENIX-4097 to deal with that once these others
are fixed.
> 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)
