From: rkinyon Date: Sat, 10 Feb 2007 18:43:15 +0000 (+0000) Subject: Article improvements X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=61b73529e4d3e05eb65393febdecf0dbf91a1d9c;p=dbsrgits%2FDBM-Deep.git Article improvements --- diff --git a/article.pod b/article.pod index b372b49..cd29c47 100644 --- a/article.pod +++ b/article.pod @@ -268,7 +268,10 @@ L). 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, 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, I mentioned that other processes modifying the HEAD will protect all running transactions from their effects. This provides I. 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 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. + +=head2 Sub-transactions + +Similar to L, 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