php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #45267 Revisit locking in DBA for DB4
Submitted: 2008-06-14 00:58 UTC Modified: 2008-06-19 22:47 UTC
From: sixd@php.net Assigned:
Status: Closed Package: DBM/DBA related
PHP Version: 5.3CVS-2008-06-14 (CVS) OS: Linux
Private report: No CVE-ID: None
View Developer Edit
 [2008-06-14 00:58 UTC] sixd@php.net 
Description:
------------
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
DBA.

See http://bugs.php.net/bug.php?id=45266 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-06-19 22:47 UTC] sixd@php.net 
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
http://snaps.php.net/.
 
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: Mon Dec 30 14:01:28 2024 UTC