[ 
https://issues.apache.org/jira/browse/HBASE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906570#action_12906570
 ] 

Todd Lipcon commented on HBASE-2957:
------------------------------------

Hm, I might have missed something in the discussion, but it seems Prakash's 
original suggestion should work. Right now we do for any edit:

1. lock rows
2. write to hlog
3. sync hlog
4. beginMemstoreInsert
5. edit memstore
6. completeMemstoreInsert
7. release locks

Instead, I think another valid order would be:

1. lock rows
2. write to hlog
3. begin memstore insert
4. edit memstore
5. unlock rows
6. sync hlog
7. complete memstore insert

The guarantee we have to provide is that we don't complete the memstore insert 
before sync, but assuming we hold that the same as today, it should be 
invisible to users but provide a speedup for all modifications except CAS. 
We'll have to be careful how this interacts with CAS, though.

> Release row lock when waiting for wal-sync
> ------------------------------------------
>
>                 Key: HBASE-2957
>                 URL: https://issues.apache.org/jira/browse/HBASE-2957
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver, wal
>    Affects Versions: 0.20.0
>            Reporter: Prakash Khemani
>
> Is there a reason to hold on to the row-lock while waiting for the WAL-sync 
> to be completed by the logSyncer thread?
> I think data consistency will be guaranteed even if the following happens (a) 
> the row lock is held while the row is updated in memory (b) the row lock is 
> released after queuing the KV record for WAL-syncing (c) the log-sync system 
> guarantees that the log records for any given row are synced in order (d) the 
> HBase client only receives a success notification after the sync completes 
> (no change from the current state)
> I think this should be a huge win. For my use case, and I am sure for others, 
>  the handler thread spends the bulk of its row-lock critical section  time 
> waiting for sync to complete.
> Even if the log-sync system cannot guarantee the orderly completion of sync 
> records, the "Don't hold row lock while waiting for sync" option should be 
> available to HBase clients on a per request basis.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to