[spambayes-dev] A new and altogether different bsddb breakage

[Kenny Pitt]

Barry Warsaw wrote:
> On Wed, 2003-12-17 at 20:16, Tim Peters wrote:
> 
>> Having never written anything myself using bsddb3's "real"
>> interface, I can't say how hard that would be.  I *expect* it would
>> actually be easy for someone with a non-trivial understanding of
>> BDB.  The only use we have for BDB now is to use it as if it were a
>> giant dict -- it probably doesn't get any simpler than that.
> 
> If you map all square-bracket setitems to .put()'s and square-bracket
> getitems to .get()'s, it's fairly straightforward.  That is, provided
> you can define the transaction boundaries so you can call txn begin,
> abort, and commit at the Right Times.  You will want to pass the BDB
> txn object into the .gets and .puts to make it all work smoothly. 
> Add a little extra goo to create the environment if it doesn't exist
> (or join it if it does), and viola!  or contrabasso!

The bsddb package includes a dbshelve module that handles all the
required dictionary access methods to provide compatibility with
standard shelve functionality.  It also allows specifying the DB_ENV
when opening the database.  The only thing it doesn't seem to handle is
transactions, but I'm not convinced we need that.

Transactions are only really important if you are updating several
related entries, and need to be able to rollback the whole lot if any
one of them fails.  There are some points in SpamBayes that could be
reworked to use transactions (e.g. rollback all token count updates for
a single message if we can't update them all), but I don't think that
has anything to do with the DbRunRecovery errors.  The important thing
re our suspected cause would be the multi-thread and multi-process
locking, and that can be used independently of transactions.

-- 
Kenny Pitt