[
https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575697#comment-13575697
]
Anoop Sam John commented on HBASE-7801:
---------------------------------------
bq.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
This also to be default to defered = false
When the attribute is missing we can assume the value to be that set for the
table?
When the attribute is there we go by that for the Mutation. And when atleast
one need WAL to be synced immediately , go with that. If all need WAL to be
defered synced or none have this attribute but at the table level it is
defered, then go with defered.
[~lhofhansl] Here batch will be the mini batch. Which all Mutations will come
under one mini batch depends on the row locking.
Another point not directly related to this issue. Now we have the LogSyncer
thread started and running. This thread can come at any point during the put
and can do a sync. If all my writes I want to be defered sync = false, this
thread may be of no real use for me. In our case of secondary indexing we
wanted the sync to happen as one operation (sync write for actual region and
that for index region). This is possible but the issue is in between the
LogSyncer thread can come and do a sync. So should we make a way to so as to
control the start of LogSyncer ?
> 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
> Fix For: 0.96.0, 0.94.6
>
>
> 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
