It is unspecified whether the apr_dbm.h interface is safe to use for 
multiple processes/threads having r/w access to a single database. 
Results appear to be:

- sdbm, gdbm are safe
- bdb, ndbm are not safe

(Berkeley DB obviously can be used in a way which is safe for multiple 
r/w users but it appears to require using one of the more complicated 
modes of operation via a DB_ENV, and changing to that would not be 
backwards compatible with the current db format. Corrections welcome, 
not a database expert)

This seems pretty bad, httpd's use of this interface depends on the DBM 
API being safe for concurrent use, but I'm not sure there is any good 
way forward.

Options I can see:

1. Implement APR-specific locking inside apr_dbm for unsafe db types, 
e.g. by creating a lockfile "<pathname>.lock" and use apr_file_lock

2. Drop concurrency-unsafe db methods... but, APR 2.x only?

3. No code change. Describe the state of concurrency-safety in the API 
for each db type.  httpd and other users would be forced to select a DB 
type appropriate to the use case.

Any other suggestions, and any preferences among the above? I'm not sure 
if 3 isn't the least bad choice unfortunately.

Regards, Joe

Reply via email to