Bug #13630 Updated: GDBM writes frequently fail during heavy traffic.

ID: 13630 Updated by: derick@php.net Reported By: cabel@panic.com -Status: Open +Status: Bogus Bug Type: DBM/DBA related Operating System: RedHat 7.1 PHP Version: 4.0.6 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately your version of PHP is too old -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Also try upgrading GDBM... Previous Comments: ------------------------------------------------------------------------ [2002-04-03 08:22:15] ege@my-lan.de OS: Tru64 4.0F apache 1.3.19 gdbm 1.8.0 i can't use gdbm, because the read only access failed, if more the one process read from the same database ------------------------------------------------------------------------ [2001-10-10 15:56:59] cabel@panic.com We're using GDBM version 1.8.0, as of May 19, 1999. We have a fairly active web site whichs pulls content from a GDBM database. Usually this access is read-only. Occasionally -- to update a counter or information -- we need to open these databases with write access. A sample line to do this: $dbm = dbmopen("facedb", "w"); Usually, this is never a problem. However, during heavy load -- when more people than usual are updating data or counters and thus needing to write to this database -- the dbmopen() call fails with the following error: "Warning: dbmopen_gdbm(itemsdb): 10 [Can't be writer], 11 [Resource temporarily unavailable] in db.php on line 5" The PHP documentation page for dbmopen() states: "Note that PHP does its own file locking in addition to any file locking that may be done by the DBM library itself." Is this true? If so, why would we be encountering this bug? I guess the first question, which I might not be qualified to answer: is this a GDBM problem, or a PHP problem? Would switching to another database style help? Can we trap this error and try again? Enough question. That's my bug report. -Cabel ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=13630&edit=1