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