Ipqbdb concurrent access analysis

Ipqbdb uses the Concurrent Data Store (CDB) model, that supports 
deadlock-free, multiple-readers/single-writer semantics, not record or 
region locking. Updates occur in two ways:
*   non-locked: as read-change-write cycles, which can overlap, and
*   locked: as lock-read-change-write, using write cursors.

In the non-locked mode, multiple programs read a given record and 
concurrently write an update. When this happens, internal bdb locking 
ensures that the relevant .db file will not be corrupted. However, all 
updates except the last one will be "lost".

A 4-second timeout value is configured by the programs.  This value can
be overridden by setting "set_lock_timeout" in DB_CONFIG.  Since 2.04,
a thread in ibd-judge monitors timeouts.


block.db
========

The block.db table is written by ibd-ban and ibd-parse using locked 
mode. The global lock ensures they don't interfere with one another. 
However, ibd-judge also writes updated records, and it currently uses 
non-locked mode. In addition, ibd-del may delete those records. That
can result in some data loss, which we deem acceptable.

As block.db can grow quite large, some operations on it may last long.
In particular, database trimming, which implies counting the records,
can lock the table for several minutes.  ibd-ban has a retry mechanism
whereby it can try to write its records for up to 90 minutes.  ibd-parse
can maintain a list of pending records; when records are pending, it is
not possible to update configuration by SIGHUP.


descr.db
========
This table is being accessed safely.

white.db
========
This is almost a read-only db. You may want to set it up with a handful of
particular IP addresses and never mind about it again. ibd-white does not
do any locking and automated updates to this table may result in unreliable
settings.


