t/28_transactions.t

   1 use strict;
   2 use Test::More tests => 4;
   3 use Test::Exception;
   4 use t::common qw( new_fh );
   5
   6 use_ok( 'DBM::Deep' );
   7
   8 my ($fh, $filename) = new_fh();
   9 my $db = DBM::Deep->new(
  10     file => $filename,
  11 );
  12
  13 $db->{x} = 'y';
  14 is( $db->{x}, 'y' );
  15 $db->begin_work;
  16 $db->{x} = 'z';
  17 is( $db->{x}, 'z' );
  18 $db->rollback;
  19 TODO: {
  20     local $TODO = "Haven't written transaction code yet";
  21     is( $db->{x}, 'y' );
  22 }
  23
  24 # Add a commit test (using fork) - we don't have to use fork initially. Since
  25 # the transaction is in the Engine object and each new() provides a new Engine
  26 # object, we're cool.
  27
  28 # Should the transaction be in the Root and not the Engine? How would that
  29 # work?
  30
  31 __END__
  32
  33 Plan for transactions:
  34 * In a normal world, every key's version is set to 0. 0 is the indication that
  35   this value isn't part of a transaction.
  36 * When a transaction is started, it is assigned the next transaction number.
  37   The engine handles the transaction, not the DBM::Deep object.
  38 * While the transaction is running, all mutations occur in parallel, not
  39   overwriting the original. They are assigned the transaction number.
  40 * How is a parallel mutation handled? It needs to be handled in the file
  41   because we don't who's going to access what from where?
  42     - Well, everything has to go through the same Engine object.
  43     - Two processes may never access the same transaction.
  44     - If a process in the middle of a transaction dies, the transaction is
  45       considered void and will be reaped during the next optimize().
  46     - So, in theory, by storing the fact that -this- file offset is involved
  47       in a transaction should be able to be stored in memory.
  48     -
  49
  50 * Every operation is now transaction-aware
  51 * If a transaction is in effect against the file, everyone ELSE has to be
  52   aware of it and respect it
  53 * Every key now has a transaction number associated with it
  54 * Every operation only operates against the key with the appropriate
  55   transaction number
  56 * In the case of %$db = (), there will need to be a 0th level to tell you
  57   which $db to go to.
  58 * Transaction #0 is the HEAD.
  59 * Upon commit, your version of reality is overlaid upon the HEAD.
  60 * Upon rollback, your version of reality disappears.
  61 * Upon process termination, an attempt is made to rollback any pending
  62   transaction(s). If ABEND, it's your responsability to optimize().
  63 * The exact actions for each tie-method will have to be mapped out.