t/28_transactions.t

   1 use strict;
   2 use Test::More tests => 13;
   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 $db1 = DBM::Deep->new(
  10     file => $filename,
  11     locking => 1,
  12     autoflush => 1,
  13 );
  14
  15 my $db2 = DBM::Deep->new(
  16     file => $filename,
  17     locking => 1,
  18     autoflush => 1,
  19 );
  20
  21 $db1->{x} = 'y';
  22 is( $db1->{x}, 'y', "Before transaction, DB1's X is Y" );
  23 is( $db2->{x}, 'y', "Before transaction, DB2's X is Y" );
  24
  25 $db1->begin_work;
  26
  27 is( $db1->{x}, 'y', "DB1 transaction started, no actions - DB1's X is Y" );
  28 is( $db2->{x}, 'y', "DB1 transaction started, no actions - DB2's X is Y" );
  29
  30 $db1->{x} = 'z';
  31 is( $db1->{x}, 'z', "Within DB1 transaction, DB1's X is Z" );
  32 is( $db2->{x}, 'y', "Within DB1 transaction, DB2's X is still Y" );
  33
  34 $db2->{other_x} = 'foo';
  35 is( $db2->{other_x}, 'foo', "DB2 set other_x within DB1's transaction, so DB2 can see it" );
  36 is( $db1->{other_x}, undef, "Since other_x was added after the transaction began, DB1 doesn't see it." );
  37
  38 $db1->rollback;
  39
  40 is( $db1->{x}, 'y', "After rollback, DB1's X is Y" );
  41 is( $db2->{x}, 'y', "After rollback, DB2's X is Y" );
  42
  43 is( $db1->{other_x}, 'foo', "After DB1 transaction is over, DB1 can see other_x" );
  44 is( $db2->{other_x}, 'foo', "After DB1 transaction is over, DB2 can still see other_x" );
  45
  46 # Add a commit test (using fork) - we don't have to use fork initially. Since
  47 # the transaction is in the Engine object and each new() provides a new Engine
  48 # object, we're cool.
  49
  50 # Should the transaction be in the Root and not the Engine? How would that
  51 # work?
  52
  53 # What about the following:
  54 #   $db->{foo} = {};
  55 #   $db2 = $db->{foo};
  56 #   $db2->begin_work;
  57 #   $db->{foo} = 3;
  58
  59 __END__
  60
  61 Plan for transactions:
  62 * In a normal world, every key's version is set to 0. 0 is the indication that
  63   this value isn't part of a transaction.
  64 * When a transaction is started, it is assigned the next transaction number.
  65   The engine handles the transaction, not the DBM::Deep object.
  66 * While the transaction is running, all mutations occur in parallel, not
  67   overwriting the original. They are assigned the transaction number.
  68 * How is a parallel mutation handled? It needs to be handled in the file
  69   because we don't who's going to access what from where?
  70     - Well, everything has to go through the same Engine object.
  71     - Two processes may never access the same transaction.
  72     - If a process in the middle of a transaction dies, the transaction is
  73       considered void and will be reaped during the next optimize().
  74     - So, in theory, by storing the fact that -this- file offset is involved
  75       in a transaction should be able to be stored in memory.
  76     -
  77
  78 * Every operation is now transaction-aware
  79 * If a transaction is in effect against the file, everyone ELSE has to be
  80   aware of it and respect it
  81 * Every key now has a transaction number associated with it
  82 * Every operation only operates against the key with the appropriate
  83   transaction number
  84 * In the case of %$db = (), there will need to be a 0th level to tell you
  85   which $db to go to.
  86 * Transaction #0 is the HEAD.
  87 * Upon commit, your version of reality is overlaid upon the HEAD.
  88 * Upon rollback, your version of reality disappears.
  89 * Upon process termination, an attempt is made to rollback any pending
  90   transaction(s). If ABEND, it's your responsability to optimize().
  91 * The exact actions for each tie-method will have to be mapped out.