Article improvements

diff --git a/article.pod b/article.pod
index b372b49..cd29c47 100644 (file)
--- a/article.pod
+++ b/article.pod
@@ -268,7 +268,10 @@ L</Staleness counters>). Committing, however, requires that all the changes
 must be transferred over from the bucket entry for the given transaction ID to
 the entry for the HEAD.
 
-This tracking is done by the modified buckets themselves. They 
+This tracking is done by the modified buckets themselves. They register
+themselves with the engine as having been modified within the transaction.
+Given L</Protection from changes>, this only guarantees that only those
+changes made by the transaction will be transferred over.
 
 =head2 Deleted marker
 
@@ -319,7 +322,7 @@ the entry was deleted.
 =head2 Staleness counters
 
 Once it was implemented for freespace management, staleness counters proved to
-be a very powerful concept for transactions themselves. Back in L<Protection
+be a very powerful concept for transactions themselves. Back in L</Protection
 from changes>, I mentioned that other processes modifying the HEAD will
 protect all running transactions from their effects. This provides
 I<Isolation>. But, the running transaction doesn't know about these entries.
@@ -334,4 +337,38 @@ acceptable tradeoff for quick delivery of a functional product.
 
 =head1 The future
 
+Basic transactions are only the first step. There are several features that
+can be added on top of what's been provided. (Note: these are advanced topics -
+I cannot be held responsible for any bleeding ears.)
+
+=head2 Conflict resolution
+
+Conflict, in this context, is what happens when two transactions run
+simultaneously and change the same piece of data. Like most databases,
+L<DBM::Deep|DBM::Deep> uses a very simplistic form of conflict resolution -
+last commit wins. This works quite well for a row-based RDBM, but doesn't work
+as well for fractal structures like hashes.
+
+Contrast this with how Subversion handles conflict. It tracks when each
+transaction was started. If the HEAD is at a later version than when the
+transaction started, the commit is rejected. It is up to the developer to pull
+in the latest changes, mediate any conflicts, and then recommit.
+
+=head2 Checkpoints
+
+A transaction may have several steps within it. The first three may succeed,
+but the fourth might fail. Instead of rolling back all the way to the
+beginning, you might want to rollback to the last successful step and try
+again. This is a checkpoint. Most RDBMSes provide them, but we'll see if users
+request them for L<DBM::Deep|DBM::Deep>.
+
+=head2 Sub-transactions
+
+Similar to L</Checkpoints>, sub-transactions provide a mechanism for trying
+something within a transaction without affecting the transaction. However,
+instead of saying "These steps are safely finished," sub-transactions still
+provides for the ability to rollback the primary transaction all the way.
+Sub-transactions can also work better with libraries that may want to use
+transactions themselves.
+
 =cut