hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7801) Allow a deferred sync option per Mutation.
Date Tue, 12 Mar 2013 12:35:13 GMT

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

Anoop Sam John commented on HBASE-7801:

1. HBaseTestCase
-      this.region.delete(delete, writeToWAL);
+      this.region.delete(delete);
Do we need to set SKIP_WAL/SYNC_WAL based on writeToWAL into Delete object?

       Delete d = new Delete(ROW);
       d.deleteColumns(FAMILIES[0], QUALIFIERS_ONE[1]);
       d.deleteColumns(FAMILIES[1], QUALIFIERS_ONE[1]);
-      this.region.delete(d, false);
+      this.region.delete(d);
Do we need to set SKIP_WAL into Delete object?

@@ -217,7 +218,7 @@
     // create new rows and column family to show how reseek works..
     for (byte[] ROW : ROWS_THREE) {
       Put p = new Put(ROW);
-      p.setWriteToWAL(true);
+      p.setWriteGuarantee(WriteGuarantee.SKIP_WAL);

-    assertEquals(true, proto.getWriteToWAL());
+    assertEquals(true, proto.getWriteGuarantee());
Assertion is wrong now. Test will fail. Other places also where assertEquals related changes
are there.

-      r.delete(new Delete(results.get(0).getRow()), false);
+      r.delete(new Delete(results.get(0).getRow()));
Do we need to set SKIP_WAL into Delete object?

-        mr.delete(new Delete(keys.get(0).getRow()), false);
+        mr.delete(new Delete(keys.get(0).getRow()));
Do we need to set SKIP_WAL into Delete object? And other similar places in this file

-    region.delete(delete, false);
+    region.delete(delete);
Do we need to set SKIP_WAL into Delete object? 
> 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,
> 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
> 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

View raw message