PDA

View Full Version : phplib-7 and dbm


em9
08-24-1999, 05:14 AM
Hi--

I am using phplib-7 for php3 with the dbm storage container. All my session data is being stored in the same dbm file. I have learned that using dbm storage is the fastest method for doing session tracking. HOWEVER...

I keep getting this error:

Warning: dbmopen_gdbm(dbm/sess.dbm): 10 [Can't be
writer], 11 [Resource temporarily unavailable] in
include/phplib/ct_dbm.inc on line 27

I assume this is because the single dbm file cannot be accessed simultaniously by multiple processes... Is my assumption correct? If so, dbm seems impossible for even a small amount of concurent users because of the likely hood of collision. PHPLIB reads the dbm file at the begining of loading a page and writes to it at the end. So the dbm file under goes a great deal of read/writing... I though file locking was supposed to handle this (?).

Thanks for any input...

Peter T. Brown
confused@em9.com

Terra
08-24-1999, 06:27 AM
I don't have the answer to your particular problem, but I do know the new DB2 dbm libraries used in the RedHat-6.0 distribution has it's own concurrent usage built in...

Right now, our server core is based on glibc2.0 libraries, and this has support for ndbm, DB_1.85...[nbsp][nbsp]glibc2.1 appears to only support DB2 now, with compatibility functions built in to access the older DB_1.85 files...

One of my own largest hurdles with RH-6.0 is that they dropped support for DB_1.85 and ndbm (which I use heavily in various areas)...[nbsp][nbsp]Due to this major core level change I seriously doubt I can ever update our production level servers, but can only start from scratch with the new servers...

At this point, you have 2 avenues...[nbsp][nbsp]Either contact the PHPLIB authors, or do some further digging on the gdbm library...

IMHO, if you are going to be using system level db libraries, then the best route is DB or MySQL...[nbsp][nbsp]At least with DB 1.85, you have a forward migration to (SleepyCat) DB2... With MySQL - it's a write once, run anytime/anywhere scenario...

This is exactly what happened to me when I tried to move QuestMail to our new server...[nbsp][nbsp]The new core database libraries (DB2) ripped it (ndbm) to shreds, and I had to move it back to NINE...

Please forgive my venting... ;)[nbsp][nbsp]I've been snagged one too many times by the various [g|s|n]dbm core database libraries...[nbsp][nbsp]I got to the point now to where I will *only* use the DB 1.85/2.0 (for the light stuff) or MySQL (for the heavier stuff)...[nbsp][nbsp]I'm also miffed, because I have to redesign the next server coming online around this unfortunate turn (upgrade) of events...

--
Terra
--Not sure what I wanted to say, but had to say it anyways--
FutureQuest
[This message has been edited by ccTech (edited 08-24-99)]