[Python-Dev] 2.3.1 is (almost) a go

[Gregory P. Smith]

> >According to info I got from Sleepycat, a DBEnv is required for using in a
> >multi-threaded environment.  Since the legacy bsddb module API is widely
> >used and use of threading has increased in the past couple years, I think 
> >we
> >need to figure out how to solve that problem.  This is just a wild-ass 
> >guess
> >(I think I posted something like it before), but maybe all that's needed is
> >to extend the bsddb.(bt|hash|rn)open functions to accept a dbenv arg, 
> >define
> >a module-level default environment in bsddb/__init__.py which is used as 
> >the
> >dbenv arg if the caller doesn't provide one.  The __init__.py code would
> >look like this:
> >
> >    _env = db.DBEnv()
> 
> I think we should define a set of flags for the "common case". In 
> general, multiple threads may write to the same database, as might 
> multiple instances of the application. IOW, we might want to create
> the environment with DB_INIT_CDB|DB_INIT_MPOOL|DB_THREAD.

It is worth noting that using a DBEnv in this manner will create a bunch
of auxilary DBEnv related files on the disk.  That has the potential of
confusing people who expect only the database file.  It also means that
separate unrelated databases cannot exist in the same directory without
being part of the same DBEnv (which BerkeleyDB multiprocess access should
handle just fine; but it might not be what people expect).

> Applications that don't want to suffer from the possible
> serialization of CDB would need to use their own environment.

An alternative would be to say that applications that want to use bsddb
with threading need to use the *real* BerkeleyDB API rather than the
ancient compatibility interface.  (it'd be easy to check that bsddb
doesn't get used by multiple threads, raising an exception if it does)

greg