view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    somewhat random order. That means that it is easy to run a "db_get"
    request on the same database as a concurrent "db_close" request, leading
    to a crash, silent data corruption, eventually the next world war on
    terrorism.

    If you only ever use foreground requests (without a callback), this will
    not be an issue (unless you use threads).

  Unexpected Freezes or Deadlocks
    Remember that, by default, BDB will execute requests in parallel, which
    easily leads to deadlocks (even concurrent put's on the same database
    can deadlock).

    You either need to run deadlock detection (and handle the resulting
    errors), or make sure only one process ever updates the database, ine
    one thread, e.g. by using only foreground requests (without a callback).

FORK BEHAVIOUR
    This module should do "the right thing" when the process using it forks:

    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 BDB has not been used
    yet.

    Win32 note: there is no fork on win32, and perls emulation of it is too
    broken to be supported, so do not use BDB in a windows pseudo-fork,
    better yet, switch to a more capable platform.

MEMORY USAGE
    Per-request usage:

    Each aio request uses - depending on your architecture - around 100-200
    bytes of memory. In addition, stat requests need a stat buffer (possibly
    a few hundred bytes), readdir requires a result buffer and so on. Perl
    scalars and other data passed into aio requests will also be locked and
    will consume memory till the request has entered the done state.

    This is not awfully much, so queuing lots of requests is not usually a
    problem.

    Per-thread usage:

    In the execution phase, some aio requests require more memory for
    temporary buffers, and each thread requires a stack and other data
    structures (usually around 16k-128k, depending on the OS).

WIN32 FILENAMES/DATABASE NAME MESS
    Perl on Win32 supports only ASCII filenames (the reason is that it
    abuses an internal flag to store wether a filename is Unicode or ANSI,
    but that flag is used for somethign else in the perl core, so there is
    no way to detect wether a filename is ANSI or Unicode-encoded). The BDB
    module tries to work around this issue by assuming that the filename is
    an ANSI filename and BDB was built for unicode support.

KNOWN BUGS
    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.

SEE ALSO
    AnyEvent::BDB (event loop integration), Coro::BDB (more natural syntax),
    IO::AIO (nice to have).

AUTHOR
     Marc Lehmann <schmorp@schmorp.de>
     http://home.schmorp.de/