[jira] [Commented] (PHOENIX-4300) Do not use preIncrementAfterRowLock for UPSERT VALUES ON DUPLICATE KEY statement

["Geoffrey Jacoby (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PHOENIX-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210234#comment-16210234 ] 

Geoffrey Jacoby commented on PHOENIX-4300:
------------------------------------------

[~jamestaylor] - would this depend on any new HBase 2.0 features or could this also go into the 1.x branch(es)? 

> Do not use preIncrementAfterRowLock for UPSERT VALUES ON DUPLICATE KEY statement
> --------------------------------------------------------------------------------
>
>                 Key: PHOENIX-4300
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4300
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>              Labels: HBase-2.0
>
> Instead of using Increment on the client and preIncrementAfterRowLock on the server (in Indexer) for UPSERT VALUES ... ON DUPLICATE KEY command, we can do the following:
> - Use regular Put with the same attributes carrying the ON DUPLICATE KEY info
> - Lock rows with ON DUPLICATE KEY info with our Phoenix-based (borrowed from HBase) locking
> - Once all rows are locked, do an mvcc.await(). This and the previous step will put the rows into the same state they were in during the preIncrementAfterRowLock hook (but actually be more efficient as we'll only do a single mvcc.await() instead of one per row).
> - Execute the {{this.builder.executeAtomicOp(inc)}} call as is done in the preIncrementAfterRowLock using the Mutation instead of the Increment
> - Add a postBatchMutate() hook and unlock the rows we locked above. Unlike with secondary index implementation, we don't need to hold the locks any longer



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)