Merge lp:~pbeaman/akiban-persistit/fix_doc_2012018 into lp:akiban-persistit

[Peter Beaman]

Two extremely minor documentation changes: (a) link to Snapshot Isolation Wikipedia page was broken, (b) a footnote in PhysicalStorage.rst was still using asciidoc markup.

NOTE: DOC ONLY DOES NOT REQUIRE A BUILD.

[Nathan Williams (nwilliams)]

Looks good.

Feel free to merge into build and push that to trunk, since going through LBJ isn't needed.

review: Approve

=== modified file 'doc/PhysicalStorage.rst'
--- doc/PhysicalStorage.rst	2012-06-11 21:25:37 +0000
+++ doc/PhysicalStorage.rst	2012-06-18 17:53:23 +0000
@@ -99,9 +99,13 @@
 
 Then Persistit locates and reapplies all transaction records in the journal for transactions that committed after the last valid checkpoint timestamp. These transactions are reapplied to the database, with the result that:
 
-- The B+Tree index and data structures are intact. All store, fetch, remove and traverse operations will complete successfully. footnote:[Persistit provides the utility class com.persistit.IntegrityCheck to verify the integrity of a Volume.]
+- The B+Tree index and data structures are intact. All store, fetch, remove and traverse operations will complete successfully.
 - All committed transactions are present in the recovered database.  (See :ref:`Transactions` for durability determined by ``CommitPolicy``.)
 
+.. note::
+
+   Persistit provides the utility class ``com.persistit.IntegrityCheck`` to verify the integrity of individual Trees or entire Volumes.
+
 For updates occurring outside of a transaction the resulting state is identical to some consistent, reasonably recent state prior to the termination. (“Reasonably recent” depends on the checkpoint interval, which by default is set to two minutes.)
 
 Flush/Force/Checkpoint

=== modified file 'doc/Transactions.rst'
--- doc/Transactions.rst	2012-06-11 21:25:37 +0000
+++ doc/Transactions.rst	2012-06-18 17:53:23 +0000
@@ -79,7 +79,7 @@
 Optimistic Transaction Scheduling
 ---------------------------------
 
-To achieve high performance and scalability, Persistit supports an optimistic transaction scheduling protocol called MVCC with http://wikipedia.org/wiki/Snapshot_isolation[Snapshot Isolation]. Under this protocol multiple threads are permitted to execute transactions at full speed without blocking until a potentially inconsistent state is recognized. At that point a transaction suspected of causing the inconsistent state is automatically forced to roll back.
+To achieve high performance and scalability, Persistit supports an optimistic transaction scheduling protocol called MVCC with `Snapshot Isolation <http://wikipedia.org/wiki/Snapshot_isolation>`_. Under this protocol multiple threads are permitted to execute transactions at full speed without blocking until a potentially inconsistent state is recognized. At that point a transaction suspected of causing the inconsistent state is automatically forced to roll back.
 
 Optimistic scheduling works because transactions usually do not collide, especially when individual database operations are fast, and so in practice transactions are seldom rolled back. But because any transaction may be rolled back at any point, applications must be designed carefully to avoid unintended side-effects. For example, a transaction should never perform non-repeatable or externally visible operations such as file or network I/O within its scope.