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

Lars Hofhansl commented on HBASE-7801:
--------------------------------------

Here's a list of changes I deliberately avoided in the 0.94 patch to keep it 
small and low risk:
* Changing the coprocessor signature. The pre/post hooks still get only a 
boolean indicating whether the entry written to the WAL or not
* Make HRegion.interalPut honor deferred sync. Currently internalPut does not 
honor this at all (not even when set on the Table); it is use for checkAndPut. 
This patch does not fix that.
* cleanup the Increment/Appand method signatures. These receive an Append (or 
Increment) and also a writeToWAL boolean, even though the Append/Increment have 
that boolean already.

If we wanted to change any of these, it should be a separate jira.

                
> Allow a deferred sync option per Mutation.
> ------------------------------------------
>
>                 Key: HBASE-7801
>                 URL: https://issues.apache.org/jira/browse/HBASE-7801
>             Project: HBase
>          Issue Type: Sub-task
>    Affects Versions: 0.94.6, 0.95.0
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>             Fix For: 0.98.0, 0.94.7, 0.95.1
>
>         Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt, 
> 7801-0.94-v4.txt, 7801-0.94-v5.txt, 7801-0.94-v6.txt, 7801-0.96-full-v2.txt, 
> 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt, 7801-0.96-full-v5.txt, 
> 7801-0.96-v10.txt, 7801-0.96-v1.txt, 7801-0.96-v6.txt, 7801-0.96-v7.txt, 
> 7801-0.96-v8.txt, 7801-0.96-v9.txt, hbase-7801-addendum.patch
>
>
> Won't have time for parent. But a deferred sync option on a per operation 
> basis comes up quite frequently.
> In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a 
> special mutation attribute.
> For batch operation we'd take the safest sync option of any of the mutations. 
> I.e. if there is at least one that wants to be flushed we'd sync the batch, 
> if there's none of those but at least one that wants deferred flush we defer 
> flush the batch, etc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to