Apache
/
hbase
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

HBASE-3903 A successful write to client write-buffer may be lost or not visible 

git-svn-id: https://svn.apache.org/repos/asf/hbase/trunk@1126735 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Michael Stack 2011-05-23 20:44:19 +00:00
parent 17f5b1872b
commit 74c41cd697
3 changed files with 21 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
CHANGES.txt
View File

@ -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)

4
src/docbkx/book.xml
View File

@ -755,6 +755,10 @@ HTable table2 = new HTable(conf2, "myTable");</programlisting>
<methodname>flushCommits()</methodname> should be invoked so Puts
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.

16
src/site/xdoc/acid-semantics.xml
View File

@ -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>