[
https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627477#comment-13627477
]
Anoop Sam John commented on HBASE-7801:
---------------------------------------
1.{code}
- byte [] row = delete.getRow();
+ delete.getRow();
{code}
We can avoid this line fully right? Good that u make some cleanup also. :)
2.{code}
// do what CF defaults to
+ if (!isDeferredLogSyncEnabled()) {
{code}
We can say do what table defaults to?
Even here also
{code}
+public enum Durability {
+ /**
+ * Use the column family's default setting to determine durability.
+ * This must remain the first option.
+ */
+ USE_DEFAULT,
{code}
3.As per code in syncOrDefer() when all the Mutations in the Mini batch says
for SKIP_WAL, we should not call the sync.
{code}
+ case SKIP_WAL:
+ // nothing do to
+ break;
{code}
But see the code in doMiniBatchMutation()
{code}
+ Durability durability = Durability.USE_DEFAULT;
...
+ Durability tmpDur = m.getDurability();
+ if (tmpDur == Durability.SKIP_WAL) {
if (m instanceof Put) {
recordPutWithoutWal(m.getFamilyMap());
}
continue;
+ } else if (tmpDur.ordinal() > durability.ordinal()) {
+ durability = tmpDur;
}
{code}
This is correct for not considering one Mutation's SKIP_WAL to affect with the
USE_DEFAULT of others. But when all the Mutation say SKIP_WAL, still finally
the durability = Durability.USE_DEFAULT and will cause a log sync?
Excellent work Lars.
> 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,
> 7801-0.96-v8.txt, 7801-0.96-v9.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
