phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-4300) Do not use preIncrementAfterRowLock for UPSERT VALUES ON DUPLICATE KEY statement
Date Wed, 18 Oct 2017 22:37:00 GMT

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

Mime
View raw message