[
https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13608302#comment-13608302
]
Enis Soztutar commented on HBASE-7801:
--------------------------------------
Two more comments:
Should we rename WriteGuarantee -> Durability, as in ACID? WriteGuarantee is
good enough, but Durability is well understood. Alternatively
DurabilityGuarantee?
In,
{code}
+ private void syncOrDefer(long txid, boolean syncRequested) throws
IOException {
+ if (this.getRegionInfo().isMetaRegion()
+ || (!this.htableDescriptor.isDeferredLogFlush() && syncRequested)
+ || this.deferredLogSyncDisabled) {
this.log.sync(txid);
}
{code}
The logic seems to be that deferred flush in HDT overrides WriteGuarantee in
Mutation. Is this intended? I think, semantically, it would be most user
friendly, if
- Durability setting in Mutation always takes precedence
- If no Durability setting in Mutation, the one in HTD takes into affect.
This allows us to do sync mutations to otherwise deferred column families, and
vice versa. This can be achieved, by defining a Durability setting in HTD
(getting rid of current skipwal and deferred stuff), and defaulting it to
SYNC_WAL. Mutation will have an optional Durability which defaults to null.
Wdyt?
> 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.95.0, 0.94.6
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.95.0, 0.98.0, 0.94.7
>
> 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
>
>
> 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
