[
https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13578193#comment-13578193
]
Lars Hofhansl commented on HBASE-7801:
--------------------------------------
[~anoopsamjohn] I was thinking that if the table is set up with deferred flush
then we'd honor that like we do now. Otherwise that option would be always
ignored unless all Mutations are marked with deferFlush (something that an old
client cannot even do).
Note that a Mutation does not explicitly say it wants to sync, it only
explicitly state when it doesn't.
Another option to make this a bit nicer is to pass the shouldSyncWal flag to
syncOrDefer and hence all the decision logic about whether to flush or not in
that method.
> 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
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.96.0, 0.94.6
>
> Attachments: 7801-0.94-v1.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
