Converted ->load calls into Engine::->load_sector() calls in order to allow better...
[dbsrgits/DBM-Deep.git] / lib / DBM / Deep / Engine.pm
CommitLineData
bf941eae 1package DBM::Deep::Engine;
2
3use 5.006_000;
4
5use strict;
6use warnings FATAL => 'all';
7
8use DBM::Deep::Iterator ();
9
10# File-wide notes:
11# * Every method in here assumes that the storage has been appropriately
12# safeguarded. This can be anything from flock() to some sort of manual
13# mutex. But, it's the caller's responsability to make sure that this has
14# been done.
15
16# Setup file and tag signatures. These should never change.
17sub SIG_FILE () { 'DPDB' }
18sub SIG_HEADER () { 'h' }
19sub SIG_HASH () { 'H' }
20sub SIG_ARRAY () { 'A' }
21sub SIG_NULL () { 'N' }
22sub SIG_DATA () { 'D' }
23sub SIG_INDEX () { 'I' }
24sub SIG_BLIST () { 'B' }
25sub SIG_FREE () { 'F' }
26sub SIG_SIZE () { 1 }
27
64a531e5 28=head1 NAME
29
30DBM::Deep::Engine
31
32=head1 PURPOSE
33
34This is an internal-use-only object for L<DBM::Deep/>. It mediates the low-level
35mapping between the L<DBM::Deep/> objects and the storage medium.
36
37The purpose of this documentation is to provide low-level documentation for
38developers. It is B<not> intended to be used by the general public. This
39documentation and what it documents can and will change without notice.
40
41=head1 OVERVIEW
42
43The engine exposes an API to the DBM::Deep objects (DBM::Deep, DBM::Deep::Array,
44and DBM::Deep::Hash) for their use to access the actual stored values. This API
45is the following:
46
47=over 4
48
49=item * new
50
51=item * read_value
52
53=item * get_classname
54
55=item * make_reference
56
57=item * key_exists
58
59=item * delete_key
60
61=item * write_value
62
63=item * get_next_key
64
f4d0ac97 65=item * setup
64a531e5 66
67=item * begin_work
68
69=item * commit
70
71=item * rollback
72
73=item * lock_exclusive
74
75=item * lock_shared
76
77=item * unlock
78
79=back
80
81They are explained in their own sections below. These methods, in turn, may
82provide some bounds-checking, but primarily act to instantiate objects in the
83Engine::Sector::* hierarchy and dispatch to them.
84
85=head1 TRANSACTIONS
86
87Transactions in DBM::Deep are implemented using a variant of MVCC. This attempts
88to keep the amount of actual work done against the file low while stil providing
89Atomicity, Consistency, and Isolation. Durability, unfortunately, cannot be done
90with only one file.
91
92=head2 STALENESS
93
94If another process uses a transaction slot and writes stuff to it, then
95terminates, the data that process wrote it still within the file. In order to
96address this, there is also a transaction staleness counter associated within
97every write. Each time a transaction is started, that process increments that
98transaction's staleness counter. If, when it reads a value, the staleness
99counters aren't identical, DBM::Deep will consider the value on disk to be stale
100and discard it.
101
102=head2 DURABILITY
103
104The fourth leg of ACID is Durability, the guarantee that when a commit returns,
105the data will be there the next time you read from it. This should be regardless
106of any crashes or powerdowns in between the commit and subsequent read.
107DBM::Deep does provide that guarantee; once the commit returns, all of the data
108has been transferred from the transaction shadow to the HEAD. The issue arises
109with partial commits - a commit that is interrupted in some fashion. In keeping
110with DBM::Deep's "tradition" of very light error-checking and non-existent
111error-handling, there is no way to recover from a partial commit. (This is
112probably a failure in Consistency as well as Durability.)
113
114Other DBMSes use transaction logs (a separate file, generally) to achieve
115Durability. As DBM::Deep is a single-file, we would have to do something
116similar to what SQLite and BDB do in terms of committing using synchonized
117writes. To do this, we would have to use a much higher RAM footprint and some
118serious programming that make my head hurts just to think about it.
119
120=cut
121
f4d0ac97 122=head2 read_value( $obj, $key )
64a531e5 123
f4d0ac97 124This takes an object that provides _base_offset() and a string. It returns the
125value stored in the corresponding Sector::Value's data section.
126
127=cut
128
129sub read_value { die "read_value must be implemented in a child class" }
130
131=head2 get_classname( $obj )
132
133This takes an object that provides _base_offset() and returns the classname (if
134any) associated with it.
135
136It delegates to Sector::Reference::get_classname() for the heavy lifting.
137
138It performs a staleness check.
139
140=cut
141
142sub get_classname { die "get_classname must be implemented in a child class" }
143
144=head2 make_reference( $obj, $old_key, $new_key )
145
146This takes an object that provides _base_offset() and two strings. The
147strings correspond to the old key and new key, respectively. This operation
148is equivalent to (given C<< $db->{foo} = []; >>) C<< $db->{bar} = $db->{foo} >>.
149
150This returns nothing.
151
152=cut
153
154sub make_reference { die "make_reference must be implemented in a child class" }
155
156=head2 key_exists( $obj, $key )
157
158This takes an object that provides _base_offset() and a string for
159the key to be checked. This returns 1 for true and "" for false.
160
161=cut
162
163sub key_exists { die "key_exists must be implemented in a child class" }
164
165=head2 delete_key( $obj, $key )
166
167This takes an object that provides _base_offset() and a string for
168the key to be deleted. This returns the result of the Sector::Reference
169delete_key() method.
170
171=cut
172
173sub delete_key { die "delete_key must be implemented in a child class" }
174
175=head2 write_value( $obj, $key, $value )
176
177This takes an object that provides _base_offset(), a string for the
178key, and a value. This value can be anything storable within L<DBM::Deep/>.
179
180This returns 1 upon success.
181
182=cut
183
184sub write_value { die "write_value must be implemented in a child class" }
185
186=head2 setup( $obj )
187
188This takes an object that provides _base_offset(). It will do everything needed
189in order to properly initialize all values for necessary functioning. If this is
190called upon an already initialized object, this will also reset the inode.
191
192This returns 1.
193
194=cut
195
196sub setup { die "setup must be implemented in a child class" }
197
198=head2 begin_work( $obj )
199
200This takes an object that provides _base_offset(). It will set up all necessary
201bookkeeping in order to run all work within a transaction.
202
203If $obj is already within a transaction, an error wiill be thrown. If there are
204no more available transactions, an error will be thrown.
205
206This returns undef.
207
208=cut
209
210sub begin_work { die "begin_work must be implemented in a child class" }
211
212=head2 rollback( $obj )
213
214This takes an object that provides _base_offset(). It will revert all
215actions taken within the running transaction.
216
217If $obj is not within a transaction, an error will be thrown.
218
219This returns 1.
220
221=cut
222
223sub rollback { die "rollback must be implemented in a child class" }
224
225=head2 commit( $obj )
226
227This takes an object that provides _base_offset(). It will apply all
228actions taken within the transaction to the HEAD.
229
230If $obj is not within a transaction, an error will be thrown.
231
232This returns 1.
233
234=cut
235
236sub commit { die "commit must be implemented in a child class" }
64a531e5 237
bf941eae 238=head2 get_next_key( $obj, $prev_key )
239
240This takes an object that provides _base_offset() and an optional string
241representing the prior key returned via a prior invocation of this method.
242
243This method delegates to C<< DBM::Deep::Iterator->get_next_key() >>.
244
245=cut
246
247# XXX Add staleness here
248sub get_next_key {
249 my $self = shift;
250 my ($obj, $prev_key) = @_;
251
f4d0ac97 252 # XXX Need to add logic about resetting the iterator if any key in the
253 # reference has changed
bf941eae 254 unless ( $prev_key ) {
255 $obj->{iterator} = DBM::Deep::Iterator->new({
256 base_offset => $obj->_base_offset,
257 engine => $self,
258 });
259 }
260
261 return $obj->{iterator}->get_next_key( $obj );
262}
263
f4d0ac97 264=head2 lock_exclusive()
265
266This takes an object that provides _base_offset(). It will guarantee that
267the storage has taken precautions to be safe for a write.
268
269This returns nothing.
270
271=cut
272
273sub lock_exclusive {
274 my $self = shift;
275 my ($obj) = @_;
276 return $self->storage->lock_exclusive( $obj );
277}
278
279=head2 lock_shared()
280
281This takes an object that provides _base_offset(). It will guarantee that
282the storage has taken precautions to be safe for a read.
283
284This returns nothing.
285
286=cut
287
288sub lock_shared {
289 my $self = shift;
290 my ($obj) = @_;
291 return $self->storage->lock_shared( $obj );
292}
293
294=head2 unlock()
295
296This takes an object that provides _base_offset(). It will guarantee that
297the storage has released the most recently-taken lock.
298
299This returns nothing.
300
301=cut
302
303sub unlock {
304 my $self = shift;
305 my ($obj) = @_;
306
307 my $rv = $self->storage->unlock( $obj );
308
309 $self->flush if $rv;
310
311 return $rv;
312}
313
314=head1 INTERNAL METHODS
315
316The following methods are internal-use-only to DBM::Deep::Engine and its
317child classes.
318
319=cut
320
321=head2 flush()
322
323This takes no arguments. It will do everything necessary to flush all things to
324disk. This is usually called during unlock() and setup().
325
326This returns nothing.
327
328=cut
329
330sub flush {
331 my $self = shift;
332
333 # Why do we need to have the storage flush? Shouldn't autoflush take care of
334 # things? -RobK, 2008-06-26
335 $self->storage->flush;
336
337 return;
338}
339
d6ecf579 340=head2 load_sector( $loc )
341
342This takes an id/location/offset and loads the sector based on the engine's
343defined sector type.
344
345=cut
346
347sub load_sector { $_[0]->sector_type->load( @_ ) }
348
349=head2 ACCESSORS
350
351The following are readonly attributes.
352
353=over 4
354
355=item * storage
356
357=back
358
359=cut
360
361sub storage { $_[0]{storage} }
362
363sub sector_type { die "sector_type must be implemented in a child class" }
364
bf941eae 3651;
366__END__