[
https://issues.apache.org/jira/browse/PHOENIX-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-4300:
----------------------------------
Description:
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
was:Instead of using Increment on the client and
> 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)
