Added footnote that there are no consistency guarantees when intra-row scanning

git-svn-id: https://svn.apache.org/repos/asf/hbase/trunk@1066345 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Michael Stack 2011-02-02 06:33:59 +00:00
parent 3a4f0f3bf1
commit 37f7a9f1f3
1 changed files with 8 additions and 3 deletions

View File

@ -136,7 +136,7 @@
<ol> <ol>
<li> <li>
Any row returned by the scan will be a consistent view (i.e. that version 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>
<li> <li>
A scan will always reflect a view of the data <em>at least as new as</em> A scan will always reflect a view of the data <em>at least as new as</em>
@ -187,7 +187,7 @@
<section name="Durability"> <section name="Durability">
<ol> <ol>
<li> All visible data is also durable data. That is to say, a read will never return <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 &quot;success&quot; code (eg does not throw an exception) <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.</li>
<li> Any operation that returns a &quot;failure&quot; code will not be made durable <li> Any operation that returns a &quot;failure&quot; code will not be made durable
@ -206,8 +206,13 @@
</section> </section>
</section> </section>
<section name="Footnotes"> <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, &quot;durably on disk&quot; implies an hflush() call on the transaction <p>[2] In the context of HBase, &quot;durably on disk&quot; 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 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 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> possible that the edits are not truly durable.</p>