r14862@rob-kinyons-computer: rob | 2007-01-18 19:51:24 -0500

 Start of my article

diff --git a/article.pod b/article.pod
new file mode 100644 (file)
index 0000000..a34f3d0
--- /dev/null
+++ b/article.pod
@@ -0,0 +1,76 @@
+=head0 Adding transactions to DBM::Deep
+
+=head1 What is DBM::Deep?
+
+L<DBM::Deep> is a module written completely in Perl that provides a way of
+storing Perl datastructures (scalars, hashes, and arrays) on disk instead of
+in memory. The datafile produced is able to be ftp'ed from one machine to
+another, regardless of OS or Perl version. There are several reasons why
+someone would want to do this.
+
+=over 4
+
+=item * Transparent Persistence
+
+This is the ability to save a set of data structures to disk and retrieve them
+later without the vast majority of the program even knowing that the data is
+persisted. Furthermore, the datastructure is persisted immediately and not at
+set marshalling periods.
+
+=item * Huge datastructures
+
+Normally, datastructures are limited by the size of RAM the server has.
+L<DBM::Deep> allows for the size a given datastructure to be limited by disk
+instead.
+
+=item * IPC
+
+While not a common use, this allows for inter-process communication without
+worrying about the specifics of how a given OS handles IPC.
+
+=back
+
+And, with the release of 1.00, there is now a fourth reason -
+software-transactional memory, or STM.
+
+=head1 What are transactions?
+
+Originally from the database world, a transaction is a way of isolating the
+effects of a given set of actions, then applying them all at once. It's a way
+of saying "I'm going to try the following steps, see if I like the result,
+then I want everyone else looking at this datastore to see the effects
+immediately." The most common example is taken from banking. Let's say that an
+application receives a request to have Joe pay Bob five zorkmids.  Without
+transactions, the application would take the money from Joe's account, then
+add the money to Bob's account. But, what happens if the application crashes
+after debiting Joe, but before crediting Bob? The application has made money
+disappear. Or, vice versa, if Bob is credited before Joe is debited, the
+application has created moneyN<Yes, the US federal government does use
+transactions, so this isn't the cause.>.
+
+With a transaction wrapping the money transfer, if the application crashes in
+the middle, it's as if the action never happened. So, when the application
+recovers from the crash, Joe and Bob still have the same amount of money in
+their accounts as they did before and the transaction can restart and Bob can
+finally receive his zorkmids.
+
+=head1 Why add them to DBM::Deep?
+
+The ability to have actions occur in either I<atomically> (as in the previous
+example) or I<isolation> from the rest of the users of the data is a powerful
+one. This allows for a certain amount of safety and predictability in how data
+transformations occur. Imagine, for example, that you have a set of
+calculations that will update various variables. However, there are some
+situations that will cause you to throw away all results and start over with a
+different seed. Without transactions, you would have to put everything into
+temporary variables, then transfer the values when the calculations were found
+to be successful. With STM, you start a transaction and do your thing within
+it. If the calculations succeed, you commit. If they fail, you rollback and
+try again. Much simpler.
+
+=head1 How it happened
+
+This project has easily been the single most complex software endeavor I've
+ever undertaken.
+
+=cut