[ https://issues.apache.org/jira/browse/PHOENIX-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210259#comment-16210259 ]
James Taylor commented on PHOENIX-4300: --------------------------------------- No, no dependencies on HBase 2.0 features. > 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)