[
https://issues.apache.org/jira/browse/PHOENIX-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-4053:
----------------------------------
Attachment: PHOENIX-4053_v4.patch
Thanks for the review, [~samarthjain]. I changed LockManager to use
ReentrantLock instead of ReentrantReadWriteLock. I also added comments and
removed a few things we don't need to simplify it. It's generally useful, so
I've left it as public for now (we can change it later if need be).
As far as locking the rows later in preBatchMutateWithExceptions, that's
problematic because we rely on setting the OperationStatus when we can't lock a
row (so that we know not to try to unlock it later). Unfortunately, there's no
mechanism to pass the RowLocks (or any other state) between coprocessor
invocations - I've filed HBASE-18482 for this. On top of that, we actually
don't need the code that's there as the client prevents any duplicates in the
batch mutate. I've filed PHOENIX-4054 for that.
> Lock row exclusively when necessary for mutable secondary indexing
> ------------------------------------------------------------------
>
> Key: PHOENIX-4053
> URL: https://issues.apache.org/jira/browse/PHOENIX-4053
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: James Taylor
> Attachments: PHOENIX-4053_4.x-HBase-0.98_v2.patch,
> PHOENIX-4053_4.x-HBase-0.98_v3.patch, PHOENIX-4053_v2.patch,
> PHOENIX-4053_v3.patch, PHOENIX-4053_v4.patch, PHOENIX-4053_wip.patch
>
>
> From HBase 1.2 on, rows are not exclusively locked when the preBatchMutate
> call is made (see HBASE-18474). The mutable secondary index (global and
> local) depend on this to get a consistent snapshot of a row between the point
> when the current row value is looked up, and when the new row is written.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
