Python has a bsddb module which exposes a simple interface based on the 1.85
API:

import bsddb
db = bsddb.hashopen("mydatabase.db", 'c')
db['fred'] = '17'
db['mary'] = 'unknown
db.close()

The latest version of the module exposes much of the current functionality,
but most applications either try to be independent of the underlying
database module used (using Python's anydbm module to select the "best"
available module) or were written before the more advanced interface was
available. Both cases preclude the use the builtin lock system available
through environment objects. (The above hashopen() call winds up calling
db_create() with a NULL env and a flags arg of 0.)

If I have a db object as defined above shared between two threads, under
what conditions do I need to acquire a lock to access it safely? Here are
the four cases:

* Both threads only read
* One thread reads, the other writes
* Both threads only write
* Both threads perform both reads and writes

It seems clear to me that no locking is necessary in the first case and that
it is absolutely required in the last two cases. What about the second
case? If thread one reads while thread two is writing, can the reader see
an inconsistent state in the db object?

How does this extend to the case of two processes, where each has opened the
database file independently?

Thanks,

Skip Montanaro
skip (AT) pobox (DOT) com

skip (AT) pobox (DOT) com (Skip Montanaro) wrote in message news:<727daa7e.0308260745.48468756 (AT) posting (DOT) google.com>...

No lock needed.

Lock needed.

Lock needed.

Lock needed.
Yes.

If each have opened the database file independently, the entire
database session (open to close) should probably be locked, as
the two processes won't share an underlying database cache, and
so may see inconsistent data.

Regards,
--keith

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic (AT) sleepycat (DOT) com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com