|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #45267 Revisit locking in DBA for DB4
Submitted: 2008-06-14 00:58 UTC Modified: 2008-06-19 22:47 UTC
From: Assigned:
Status: Closed Package: DBM/DBA related
PHP Version: 5.3CVS-2008-06-14 (CVS) OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
New email:
PHP Version: OS:


 [2008-06-14 00:58 UTC]
The locking for DBA with DB4 needs to be revisited.

The way DB_INIT_LOCK and DB_FCNTL_LOCKING are passed to DB4, and
the use of DBA_LOCK_EXT in dba.c seem to be based on the assumption
that BDB will do locking.  This isn't true with the way BDB is used by

See for why DB_INIT_LOCK isn't
valid.  DB_FCNTL_LOCKING is undocumented.  It implies that PHP does
locking. It just tells BDB when to release file handles.

Perhaps the easiest solution is for dba.c to use DBA_LOCK_ALL, but
I'm not fully aware of the implications of this flag.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-06-19 22:47 UTC]
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

DBA with BDB 4 nows uses DBA's file locking so datafile corruption should no longer be possible.

A side effect of re-introducing DBA-enforced locking is that "reading during write" (see tests/dba_db4.phpt) is not allowed. This is consistent with all other DBA drivers.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Jul 16 16:01:27 2024 UTC