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

Enis Soztutar commented on HBASE-7801:
--------------------------------------

API looks good. A couple of comments: 
 - There are still some places referring writeGuarantee, useWriteGuarantee, or 
wg. Could you please change those to be consistent. 
 - We rely on Durability enum ordinals being in ascending sorted order in terms 
of their semantic guarantees. We should note this in the enum definitions. Does 
it make sense to allow more room in between? Just thinking out loud, fsync ack 
from majority of replicas, etc? 
 - Durability.java need InterfaceAudience annotations. 
 - Should we add some pointers in SYNC_WAL, and FSYNC_WAL javadocs to hflush, 
hsync semantics? It might be confusing to first time comers. Can do as a follow 
up. 
 - Should BaseRowProcessor#useWriteGuarantee() return USE_DEFAULT? It is not 
used, but for documentation, and further reference. 


                
> 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.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-v1.txt, 7801-0.96-v6.txt, 7801-0.96-v7.txt
>
>
> 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