[ 
https://issues.apache.org/jira/browse/PHOENIX-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16106696#comment-16106696
 ] 

Andrew Purtell commented on PHOENIX-4053:
-----------------------------------------

ConcurrentMutationsIT needs an ASF header.

A concern here:
{code}
+        
+        int rowLockWaitDuration = 
clonedConfig.getInt("hbase.rowlock.wait.duration",
+                DEFAULT_ROWLOCK_WAIT_DURATION);
+        this.lockManager = new LockManager(rowLockWaitDuration);
{code}

is in HBASE-17210 we've plumbed through the client's desired RPC timeout to the 
rowlock timeout, and if not also done on the Phoenix side in lock management 
there it will undo it.

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

Reply via email to