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