phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <>
Subject [jira] [Updated] (PHOENIX-4053) Lock row exclusively when necessary for mutable secondary indexing
Date Sun, 30 Jul 2017 21:38:02 GMT


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:
>             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

View raw message