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

Gregory P. Smith greg at electricrain.com
Sat Sep 27 16:51:47 EDT 2003

>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 DBINITCDB|DBINITMPOOL|DBTHREAD.

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

More information about the Python-Dev mailing list