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