hbase-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From st...@apache.org
Subject svn commit: r1126735 - in /hbase/trunk: CHANGES.txt src/docbkx/book.xml src/site/xdoc/acid-semantics.xml
Date Mon, 23 May 2011 20:44:19 GMT
Author: stack
Date: Mon May 23 20:44:19 2011
New Revision: 1126735

URL: http://svn.apache.org/viewvc?rev=1126735&view=rev
Log:
HBASE-3903 A successful write to client write-buffer may be lost or not visible

Modified:
    hbase/trunk/CHANGES.txt
    hbase/trunk/src/docbkx/book.xml
    hbase/trunk/src/site/xdoc/acid-semantics.xml

Modified: hbase/trunk/CHANGES.txt
URL: http://svn.apache.org/viewvc/hbase/trunk/CHANGES.txt?rev=1126735&r1=1126734&r2=1126735&view=diff
==============================================================================
--- hbase/trunk/CHANGES.txt (original)
+++ hbase/trunk/CHANGES.txt Mon May 23 20:44:19 2011
@@ -110,6 +110,8 @@ Release 0.91.0 - Unreleased
    HBASE-3826  Minor compaction needs to check if still over
                compactionThreshold after compacting (Nicolas Spiegelberg)  
    HBASE-3912  [Stargate] Columns not handle by Scan
+   HBASE-3903  A successful write to client write-buffer may be lost or not
+               visible (Doug Meil)
 
   IMPROVEMENTS
    HBASE-3290  Max Compaction Size (Nicolas Spiegelberg via Stack)  

Modified: hbase/trunk/src/docbkx/book.xml
URL: http://svn.apache.org/viewvc/hbase/trunk/src/docbkx/book.xml?rev=1126735&r1=1126734&r2=1126735&view=diff
==============================================================================
--- hbase/trunk/src/docbkx/book.xml (original)
+++ hbase/trunk/src/docbkx/book.xml Mon May 23 20:44:19 2011
@@ -753,8 +753,12 @@ HTable table2 = new HTable(conf2, "myTab
                is filled.  The writebuffer is 2MB by default.  Before an HTable instance
is
                discarded, either <methodname>close()</methodname> or
                <methodname>flushCommits()</methodname> should be invoked so Puts
-               will not be lost. 
-	   </para> 
+               will not be lost.   
+	      </para> 
+	      <para>Note: <code>htable.delete(Delete);</code> does not go in the
writebuffer!  This only applies to Puts.   
+	      </para>
+	      <para>For additional information on write durability, review the <link xlink:href="acid-semantics.html">ACID
semantics</link> page.
+	      </para>
        <para>For fine-grained control of batching of
            <classname>Put</classname>s or <classname>Delete</classname>s,
            see the <link xlink:href="http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HTable.html#batch%28java.util.List%29">batch</link>
methods on HTable.

Modified: hbase/trunk/src/site/xdoc/acid-semantics.xml
URL: http://svn.apache.org/viewvc/hbase/trunk/src/site/xdoc/acid-semantics.xml?rev=1126735&r1=1126734&r2=1126735&view=diff
==============================================================================
--- hbase/trunk/src/site/xdoc/acid-semantics.xml (original)
+++ hbase/trunk/src/site/xdoc/acid-semantics.xml Mon May 23 20:44:19 2011
@@ -90,7 +90,7 @@
       <section name="Atomicity">
 
         <ol>
-          <li>All mutations are atomic within a row. Any put will either wholely succeed
or wholely fail.</li>
+          <li>All mutations are atomic within a row. Any put will either wholely succeed
or wholely fail.[3]</li>
           <ol>
             <li>An operation that returns a &quot;success&quot; code has completely
succeeded.</li>
             <li>An operation that returns a &quot;failure&quot; code has completely
failed.</li>
@@ -170,7 +170,7 @@
         <ol>
           <li> When a client receives a &quot;success&quot; response for any
mutation, that
           mutation is immediately visible to both that client and any client with whom it
-          later communicates through side channels.</li>
+          later communicates through side channels. [3]</li>
           <li> A row must never exhibit so-called &quot;time-travel&quot; properties.
That
           is to say, if a series of mutations moves a row sequentially through a series of
           states, any sequence of concurrent reads will return a subsequence of those states.</li>
@@ -189,7 +189,7 @@
           <li> All visible data is also durable data. That is to say, a read will never
return
           data that has not been made durable on disk[2]</li>
           <li> Any operation that returns a &quot;success&quot; code (eg does
not throw an exception)
-          will be made durable.</li>
+          will be made durable.[3]</li>
           <li> Any operation that returns a &quot;failure&quot; code will not
be made durable
           (subject to the Atomicity guarantees above)</li>
           <li> All reasonable failure scenarios will not affect any of the guarantees
of this document.</li>
@@ -205,6 +205,12 @@
         </ul>
       </section>
     </section>
+    <section name="More Information">
+      <p>
+      For more information, see the <a href="book.html#client">client architecture</a>
or <a href="book.html#datamodel">data model</a> sections in the HBase book. 
+      </p>
+    </section>
+    
     <section name="Footnotes">
       <p>[1] A consistent view is not guaranteed intra-row scanning -- i.e. fetching
a portion of
           a row in one RPC then going back to fetch another portion of the row in a subsequent
RPC.
@@ -216,6 +222,10 @@
       log. This does not actually imply an fsync() to magnetic media, but rather just that
the data has been
       written to the OS cache on all replicas of the log. In the case of a full datacenter
power loss, it is
       possible that the edits are not truly durable.</p>
+      <p>[3] Puts will either wholely succeed or wholely fail, provided that they are
actually sent
+      to the RegionServer.  If the writebuffer is used, Puts will not be sent until the writebuffer
is filled
+      or it is explicitly flushed.</p>
+      
     </section>
 
   </body>



Mime
View raw message