$db->clear(); # hashes or arrays
-=item * lock() / unlock()
+=item * lock() / unlock() / lock_exclusive() / lock_shared()
q.v. L</LOCKING> for more info.
=head2 Explicit Locking
You can explicitly lock a database, so it remains locked for multiple
-actions. This is done by calling the C<lock()> method, and passing an
-optional lock mode argument (defaults to exclusive mode). This is particularly
-useful for things like counters, where the current value needs to be fetched,
-then incremented, then stored again.
+actions. This is done by calling the C<lock_exclusive()> method (for when you
+want to write) or the C<lock_shared()> method (for when you want to read).
+This is particularly useful for things like counters, where the current value
+needs to be fetched, then incremented, then stored again.
- $db->lock();
+ $db->lock_exclusive();
my $counter = $db->get("counter");
$counter++;
$db->put("counter", $counter);
# or...
- $db->lock();
+ $db->lock_exclusive();
$db->{counter}++;
$db->unlock();
-You can pass C<lock()> an optional argument, which specifies which mode to use
-(exclusive or shared). Use one of these two constants:
-C<DBM::Deep-E<gt>LOCK_EX> or C<DBM::Deep-E<gt>LOCK_SH>. These are passed
-directly to C<flock()>, and are the same as the constants defined in Perl's
-L<Fcntl> module.
-
- $db->lock( $db->LOCK_SH );
- # something here
- $db->unlock();
-
=head2 Win32/Cygwin
Due to Win32 actually enforcing the read-only status of a shared lock, all
=head2 Caching
-If a user is willing to assert upon opening the file that this process will be
+If a client is willing to assert upon opening the file that this process will be
the only consumer of that datafile, then there are a number of caching
possibilities that can be taken advantage of. This does, however, mean that
DBM::Deep is more vulnerable to losing data due to unflushed changes. It also
single-process. I have no idea how I'd specify this, though. Suggestions are
welcome.
-=head2 Importing using Data::Walker
-
-Right now, importing is done using C<Clone::clone()> to make a complete copy
-in memory, then tying that copy. It would be much better to use
-L<Data::Walker> to walk the data structure instead, particularly in the case
-of large datastructures.
-
=head2 Different contention resolution mechanisms
Currently, the only contention resolution mechanism is last-write-wins. This
on DBM::Deep, as every element has to be fetched from disk, then stored again in
a different location. This will be addressed in a future version.
+This has been somewhat addressed so that the cost is constant, regardless of
+what is stored at those locations. So, small arrays with huge data structures in
+them are faster. But, large arrays are still large.
+
=head2 Writeonly Files
-If you pass in a filehandle to new(), you may have opened it in either a readonly or
-writeonly mode. STORE will verify that the filehandle is writable. However, there
-doesn't seem to be a good way to determine if a filehandle is readable. And, if the
-filehandle isn't readable, it's not clear what will happen. So, don't do that.
+If you pass in a filehandle to new(), you may have opened it in either a
+readonly or writeonly mode. STORE will verify that the filehandle is writable.
+However, there doesn't seem to be a good way to determine if a filehandle is
+readable. And, if the filehandle isn't readable, it's not clear what will
+happen. So, don't do that.
=head2 Assignments Within Transactions
or send email to L<DBM-Deep@googlegroups.com>. You can also visit #dbm-deep on
irc.perl.org
-The source code repository is at L<http://svn.perl.org/modules/DBM-Deep>
+The source code repository is at L<http://github.com/robkinyon/dbm-deep>
=head1 MAINTAINERS