Re: [PHP-DB] gdbm locking problem
I don't use GDBM, but it looks like you have the wrong idea completely.
dba_open will return a database connection handle, if its successful,
there is no sense opening up multiple database handles in a loop like
that. dba_open will do locking itself, the d in wd tells it to use a
file lock, the w tells it to allow read/write access.
$id = dba_open (/tmp/test.db, n, db2);
if (!$id) {
echo dba_open failed\n;
exit;
}
Read this: http://us2.php.net/manual/en/function.dba-open.php
*Note: * Locking and the mode modifiers l, d, - and t were added
in PHP 4.3.0. In PHP versions before PHP 4.3.0 you must use semaphores
to guard against simultaneous database access for any database handler
with the exception of GDBM. See System V semaphore support
http://us2.php.net/manual/en/ref.sem.php.
-Jeff Moss
Michael Jeung wrote:
Hello everyone,
I am having trouble with gdbm locking. I've written two very simple
test scripts that I am running simultaneously and locking does not
seem to be working properly.
1st Test Script - Opens a writer lock, then spins infinitely.
dba_open(research.db, wd, gdbm);
while(1) {
echo I have a writer lock on the file! \n;
}
2nd Test Script: - Spins infinitely, trying to get a write lock on the
file.
while(1) {
if(dba_open(research.db, wd, gdbm))
echo I also have a write lock on the file! (using dba_open) \n;
}
Here is the problem: When I run Script 1 and then Script 2 (while
Script 1 is running), both scripts claim to have a writer lock on
research.db. This doesn't seem right. What am I missing?
I'm running both of the scripts in the same directory on the same
machine under FreeBSD 4.10.
Thanks for your help!
Michael Jeung
Re: [PHP-DB] Sybase Peristent Connections Gotchas
The biggest problem I've had with persistent connections is the problems that arise when the connection goes down. You have to monitor the connection status anyways (and reconnect on a failure), so it was usually easier to just connect every time. I don't know if this is specific to sybase. You also avoid headache dealing with multiple connections per process. Over a local ethernet this was usually such a short delay that it didn't matter. Typically I don't care much for speed, you avoid a lot of headache avoiding the persistent connections, but the tradeoff is speed of course. It seems to make a lot more sense to me to just reset the handle to drop all temp tables and that. As for the transactions, I think as long as you do the transaction all at once there would be no problem right? If it was a problem in the middle of a socket write, chances are the socket closed also, right? -Jeff Brian Foddy wrote: I've been using PHP4/5 and Sybase for several years, using standard sybase_connect. Today I tried playing around with pconnect to get aquainted. I expected one simple condition of a use database from one web page affecting another, and easilly handled that with a connection wrapper that re-uses the proper database with each reconnection. A couple other more troublesome issues also quickly came up. 1. Any #temp database tables are not destroyed between calls. I can probably work around this with some minor coding changes to manually drop temp tables. 2. Any call to environmental set commands like set isolation remain in effect after the web page is complete. Again with some work I could probably recode some pages to not change these values, or reset them when complete. 3. The potentially most bothersome would be a page failing to call commit tran/rollback tran, especially during some error condition. Its easy to think any uncommited tran is rolled back when the page exists. But persistent connections won't do this. This could be a disaster by leaving open a transaction causing all subsequent calls to never be commited... I might be able to create some wrapper that always resets the transaction state before starting?? I'm curious how others have attempted to solve these problems, and others I haven't thought of yet. Clearly many can be avoided by having clean code, but just 1 exception... Brian -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
