[
https://issues.apache.org/jira/browse/PHOENIX-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-4053:
----------------------------------
Description:
>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, until the
>mvcc is advanced. Otherwise, a subsequent update to a row may not see the
>current row state. Even with pre HBase 1.2 releases, the lock isn't held long
>enough for us. We need to hold the locks from the start of the preBatchMutate
>(when we read the data table to get the prior row values) until the mvcc is
>advanced (beginning of postBatchMutateIndispensably).
Given the above, it's best if Phoenix manages the row locking itself (mimicing
the current HBase mechanism).
was: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.
> 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-4.x-HBase-0.98_v4.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,
> until the mvcc is advanced. Otherwise, a subsequent update to a row may not
> see the current row state. Even with pre HBase 1.2 releases, the lock isn't
> held long enough for us. We need to hold the locks from the start of the
> preBatchMutate (when we read the data table to get the prior row values)
> until the mvcc is advanced (beginning of postBatchMutateIndispensably).
> Given the above, it's best if Phoenix manages the row locking itself
> (mimicing the current HBase mechanism).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
