Author: stack
Date: Wed Feb 2 06:33:59 2011
New Revision: 1066345
URL: http://svn.apache.org/viewvc?rev=1066345&view=rev
Log:
Added footnote that there are no consistency guarantees when intra-row scanning
Modified:
hbase/trunk/src/site/xdoc/acid-semantics.xml
Modified: hbase/trunk/src/site/xdoc/acid-semantics.xml
URL:
http://svn.apache.org/viewvc/hbase/trunk/src/site/xdoc/acid-semantics.xml?rev=1066345&r1=1066344&r2=1066345&view=diff
==============================================================================
--- hbase/trunk/src/site/xdoc/acid-semantics.xml (original)
+++ hbase/trunk/src/site/xdoc/acid-semantics.xml Wed Feb 2 06:33:59 2011
@@ -136,7 +136,7 @@
<ol>
<li>
Any row returned by the scan will be a consistent view (i.e. that
version
- of the complete row existed at some point in time)
+ of the complete row existed at some point in time) [1]
</li>
<li>
A scan will always reflect a view of the data <em>at least as new
as</em>
@@ -187,7 +187,7 @@
<section name="Durability">
<ol>
<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[1]</li>
+ data that has not been made durable on disk[2]</li>
<li> Any operation that returns a "success" code (eg does
not throw an exception)
will be made durable.</li>
<li> Any operation that returns a "failure" code will not
be made durable
@@ -206,8 +206,13 @@
</section>
</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.
+ Intra-row scanning happens when you set a limit on how many values
to return per Scan#next
+ (See <a
href="http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Scan.html#setBatch(int)">Scan#setBatch(int)</a>).
+ </p>
- <p>[1] In the context of HBase, "durably on disk" implies an
hflush() call on the transaction
+ <p>[2] In the context of HBase, "durably on disk" implies an
hflush() call on the transaction
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>
