From: rkinyon Date: Fri, 19 Jan 2007 06:40:12 +0000 (+0000) Subject: r14862@rob-kinyons-computer: rob | 2007-01-18 19:51:24 -0500 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=315b34ebce01eea2734e9d713984fa8c9ea2ad16;p=dbsrgits%2FDBM-Deep.git 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 index 0000000..a34f3d0 --- /dev/null +++ b/article.pod @@ -0,0 +1,76 @@ +=head0 Adding transactions to DBM::Deep + +=head1 What is DBM::Deep? + +L 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 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. + +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 (as in the previous +example) or I 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