[ViewVC] Diff of: cvs/BDB/BDB.pm

Comparing BDB/BDB.pm (file contents):
Revision 1.14 by root, Thu Sep 13 12:29:49 2007 UTC vs.
Revision 1.19 by root, Wed Dec 5 13:01:46 2007 UTC

 BDB - Asynchronous Berkeley DB access
 =head1 SYNOPSIS
  use BDB;
+ my $env = db_env_create;
+ mkdir "bdtest", 0700;
+ db_env_open
+    $env,
+    "bdtest",
+    BDB::INIT_LOCK | BDB::INIT_LOG | BDB::INIT_MPOOL
+    | BDB::INIT_TXN | BDB::RECOVER | BDB::USE_ENVIRON | BDB::CREATE,
+    0600;
+ $env->set_flags (BDB::AUTO_COMMIT | BDB::TXN_NOSYNC, 1);
+ my $db = db_create $env;
+ db_open $db, undef, "table", undef, BDB::BTREE, BDB::AUTO_COMMIT | BDB::CREATE
+                                     | BDB::READ_UNCOMMITTED, 0600;
+ db_put $db, undef, "key", "data", 0, sub {
+    db_del $db, undef, "key";
+ };
+ db_sync $db;
+ # automatic result processing with AnyEvent:
+ our $FH; open $FH, "<&=" . BDB::poll_fileno;
+ our $WATCHER = AnyEvent->io (fh => $FH, poll => 'r', cb => \&BDB::poll_cb);
+ # automatic result processing with EV:
+ my $WATCHER = EV::io BDB::poll_fileno, EV::READ, \&BDB::poll_cb;
+ # with Glib:
+ add_watch Glib::IO BDB::poll_fileno,
+           in => sub { BDB::poll_cb; 1 };
+ # or simply flush manually
+ BDB::flush;
 =head1 DESCRIPTION
 See the BerkeleyDB documentation (L<http://www.oracle.com/technology/documentation/berkeley-db/db/index.html>).
 The BDB API is very similar to the C API (the translation has been very faithful).
 use strict 'vars';
 use base 'Exporter';
 BEGIN {
-   our $VERSION = '1.0';
+   our $VERSION = '1.2';
    our @BDB_REQ = qw(
       db_env_open db_env_close db_env_txn_checkpoint db_env_lock_detect
       db_env_memp_sync db_env_memp_trickle
       db_open db_close db_compact db_sync db_put db_get db_pget db_del db_key_range
-      db_txn_commit db_txn_abort
+      db_txn_commit db_txn_abort db_txn_finish
       db_c_close db_c_count db_c_put db_c_get db_c_pget db_c_del
       db_sequence_open db_sequence_close
       db_sequence_get db_sequence_remove
    );
    our @EXPORT = (@BDB_REQ, qw(dbreq_pri dbreq_nice db_env_create db_create));
    db_sequence_get (DB_SEQUENCE *seq, DB_TXN_ornull *txnid, int delta, SV *seq_value, U32 flags = DB_TXN_NOSYNC, SV *callback = &PL_sv_undef)
       flags: TXN_NOSYNC
    db_sequence_remove (DB_SEQUENCE *seq, DB_TXN_ornull *txnid = 0, U32 flags = 0, SV *callback = &PL_sv_undef)
       flags: TXN_NOSYNC
+=head4 db_txn_finish (DB_TXN *txn, U32 flags = 0, SV *callback = &PL_sv_undef)
+This is not actually a Berkeley DB function but a BDB module
+extension. The background for this exytension is: It is very annoying to
+have to check every single BDB function for error returns and provide a
+codepath out of your transaction. While the BDB module still makes this
+possible, it contains the following extensions:
+When a transaction-protected function returns any operating system
+error (errno > 0), BDB will set the C<TXN_DEADLOCK> flag on the
+transaction. This flag is also set by Berkeley DB functions themselves
+when an operation fails with LOCK_DEADLOCK, and it causes all further
+operations on that transaction (including C<db_txn_commit>) to fail.
+The C<db_txn_finish> request will look at this flag, and, if it is set,
+will automatically call C<db_txn_abort> (setting errno to C<LOCK_DEADLOCK>
+if it isn't set to something else yet). If it isn't set, it will call
+C<db_txn_commit> and return the error normally.
+How to use this? Easy: just write your transaction normally:
+   my $txn = $db_env->txn_begin;
+   db_get $db, $txn, "key", my $data;
+   db_put $db, $txn, "key", $data + 1 unless $! == BDB::NOTFOUND;
+   db_txn_finish $txn;
+   die "transaction failed" if $!;
+That is, handle only the expected errors. If something unexpected happens
+(EIO, LOCK_NOTGRANTED or a deadlock in either db_get or db_put), then the remaining
+requests (db_put in this case) will simply be skipped (they will fail with
+LOCK_DEADLOCK) and the transaction will be aborted.
+You can use the C<< $txn->failed >> method to check wether a transaction
+has failed in this way and abort further processing (excluding
+C<db_txn_finish>).
 =head3 DB_ENV/database environment methods
 Methods available on DB_ENV/$env handles:
    DESTROY (DB_ENV_ornull *env)
    $int = $env->set_flags (U32 flags, int onoff)
    $env->set_errfile (FILE *errfile = 0)
    $env->set_msgfile (FILE *msgfile = 0)
    $int = $env->set_verbose (U32 which, int onoff = 1)
    $int = $env->set_encrypt (const char *password, U32 flags = 0)
-   $int = $env->set_timeout (NV timeout, U32 flags)
+   $int = $env->set_timeout (NV timeout_seconds, U32 flags = SET_TXN_TIMEOUT)
    $int = $env->set_mp_max_openfd (int maxopenfd);
    $int = $env->set_mp_max_write (int maxwrite, int maxwrite_sleep);
    $int = $env->set_mp_mmapsize (int mmapsize_mb)
    $int = $env->set_lk_detect (U32 detect = DB_LOCK_DEFAULT)
    $int = $env->set_lk_max_lockers (U32 max)
    DESTROY (DB_TXN_ornull *txn)
            CODE:
            if (txn)
              txn->abort (txn);
-   $int = $txn->set_timeout (NV timeout, U32 flags)
+   $int = $txn->set_timeout (NV timeout_seconds, U32 flags = SET_TXN_TIMEOUT)
       flags: SET_LOCK_TIMEOUT SET_TXN_TIMEOUT
+   $bool = $txn->failed
+   # see db_txn_finish documentation, above
 =head3 DBC/cursor methods
 Methods available on DBC/$dbc handles:
 interactiveness when perl is not fast enough to process all requests in
 time.
 For interactive programs, values such as C<0.01> to C<0.1> should be fine.
-Example: Install an Event watcher that automatically calls
+Example: Install an EV watcher that automatically calls
 BDB::poll_cb with low priority, to ensure that other parts of the
-program get the CPU sometimes even under high AIO load.
+program get the CPU sometimes even under high load.
    # try not to spend much more than 0.1s in poll_cb
    BDB::max_poll_time 0.1;
-   # use a low priority so other tasks have priority
+   my $bdb_poll = EV::io BDB::poll_fileno, EV::READ, \&BDB::poll_cb);
-   Event->io (fd => BDB::poll_fileno,
-              poll => 'r', nice => 1,
-              cb => &BDB::poll_cb);
 =item BDB::poll_wait
 If there are any outstanding requests and none of them in the result
 phase, wait till the result filehandle becomes ready for reading (simply
    BDB::poll_wait, BDB::poll_cb
 =item BDB::flush
-Wait till all outstanding AIO requests have been handled.
+Wait till all outstanding BDB requests have been handled.
 Strictly equivalent to:
    BDB::poll_wait, BDB::poll_cb
       while BDB::nreqs;
 =over 4
 =item BDB::min_parallel $nthreads
-Set the minimum number of AIO threads to C<$nthreads>. The current
+Set the minimum number of BDB threads to C<$nthreads>. The current
 default is C<8>, which means eight asynchronous operations can execute
 concurrently at any one time (the number of outstanding requests,
 however, is unlimited).
-BDB starts threads only on demand, when an AIO request is queued and
+BDB starts threads only on demand, when an BDB request is queued and
 no free thread exists. Please note that queueing up a hundred requests can
 create demand for a hundred threads, even if it turns out that everything
 is in the cache and could have been processed faster by a single thread.
 It is recommended to keep the number of threads relatively low, as some
 Under most circumstances you don't need to call this function, as the
 module selects a default that is suitable for low to moderate load.
 =item BDB::max_parallel $nthreads
-Sets the maximum number of AIO threads to C<$nthreads>. If more than the
+Sets the maximum number of BDB threads to C<$nthreads>. If more than the
 specified number of threads are currently running, this function kills
 them. This function blocks until the limit is reached.
 While C<$nthreads> are zero, aio requests get queued but not executed
 until the number of threads has been increased again.
 =head2 FORK BEHAVIOUR
 This module should do "the right thing" when the process using it forks:
-Before the fork, IO::AIO enters a quiescent state where no requests
+Before the fork, BDB enters a quiescent state where no requests
 can be added in other threads and no results will be processed. After
 the fork the parent simply leaves the quiescent state and continues
 request/result processing, while the child frees the request/result queue
 (so that the requests started before the fork will only be handled in the
 parent). Threads will be started on demand until the limit set in the
 parent process has been reached again.
 In short: the parent will, after a short pause, continue as if fork had
-not been called, while the child will act as if IO::AIO has not been used
+not been called, while the child will act as if BDB has not been used
 yet.
 =head2 MEMORY USAGE
 Per-request usage:
 temporary buffers, and each thread requires a stack and other data
 structures (usually around 16k-128k, depending on the OS).
 =head1 KNOWN BUGS
-Known bugs will be fixed in the next release.
+Known bugs will be fixed in the next release, except:
+   If you use a transaction in any request, and the request returns
+   with an operating system error or DB_LOCK_NOTGRANTED, the internal
+   TXN_DEADLOCK flag will be set on the transaction. See C<db_txn_finish>,
+   above.
 =head1 SEE ALSO
-L<Coro::AIO>.
+L<Coro::BDB>, L<IO::AIO>.
 =head1 AUTHOR
  Marc Lehmann <schmorp@schmorp.de>
  http://home.schmorp.de/

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing BDB/BDB.pm (file contents): Revision 1.14 by root, Thu Sep 13 12:29:49 2007 UTC vs. Revision 1.19 by root, Wed Dec 5 13:01:46 2007 UTC

Diff Legend

Comparing BDB/BDB.pm (file contents):
Revision 1.14 by root, Thu Sep 13 12:29:49 2007 UTC vs.
Revision 1.19 by root, Wed Dec 5 13:01:46 2007 UTC