[
https://issues.apache.org/jira/browse/PHOENIX-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16106705#comment-16106705
]
James Taylor commented on PHOENIX-4053:
---------------------------------------
Looks like HBASE-17210 isn't available in 1.3. I could potentially hack around
it by putting LockManager in the org.apache.hadoop.hbase.ipc package, adding
some casts, and referencing deadline directly like this:
{code}
RpcServer.Call call = (RpcServer.Call)RpcServer.getCurrentCall();
if (call != null && call.deadline < Long.MAX_VALUE) {
int timeToDeadline = (int)(call.deadline -
System.currentTimeMillis());
if (timeToDeadline <= this.rowLockWaitDuration) {
reachDeadlineFirst = true;
timeout = timeToDeadline;
}
}
{code}
WDYT, [~apurtell]? Too ugly, wait for 1.4 release for Phoenix, or is this ok?
> 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)
