ID: 6798 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: Informix related Operating System: Solaris 2.5.1 PHP Version: 4.0.2 Assigned To: danny New Comment:
This is should be fixed in CVS. Try the latest CVS snapshot from http://snaps.php.net/ and reopen this bug report if you get the same problems. --Jani Previous Comments: ------------------------------------------------------------------------ [2000-11-01 12:14:53] [EMAIL PROTECTED] I guess this one should be 'assigned' not 'feedback' ? --Jani ------------------------------------------------------------------------ [2000-09-21 02:22:01] [EMAIL PROTECTED] I had a look at the nsapi.c source, and it needs "ZTS" defined, so I think --with-nsapi enables threads. The Informix driver has never been tested with threads. The code is supposed to be thread-safe, but you need to add the -thread compiler flag to the esql command to link in the Informix thread-safe libraries. Best way to test this would be to edit the configure script I guess. Even then, I don't know if different threads within the same process are allowed the use of the same descriptor names. The driver currently has a "globals" area per thread when compiled with ZTS, so that each thread has it's own counters for generating the cursor names, descriptor names etc..., so that all threads will end up with the same sequence of genereated names. With the Apache module, each instance of PHP4 resides within a different Unix process, so that name clashes are not possible. I could use process-global variables instead for this, but then I would have to protect them with critical sections or mutexes. This way the names would be unique within the same process regardless of the number of threads at the expense of some overhead. I don't know what the PHP4 way of doing mutexes is, as I have never needed this before, I will have to investigate this. Danny --- ------------------------------------------------------------------------ [2000-09-20 04:27:41] [EMAIL PROTECTED] Yes, this is the NSAPI version. I haven't done anything w/threads. Here's the configure line I use: [root@ina php-4.0.2]# ./configure --with-nsapi=/web --with-pdflib --with-cybercash=/ina/mck-3.2.0.4-solaris-sparc --with-gdbm --with-dom=/usr/local --with-fdftk --enable-ftp --with-gd=../gd-1.8.3 --with-ttf --with-imap --with-informix=/usr/local/informix --with-mysql=/usr/local/mysql --with-esoob=/usr/local/easysoft/oob/client --enable-wddx --enable-trans-sid Should I be adding one of the tsrm options? If you relevant parts of config.log, I can add those as well. ------------------------------------------------------------------------ [2000-09-20 02:47:01] [EMAIL PROTECTED] Is this the NSAPI version ? Is the thread-safe code enabled ? Descriptor names are generated from a global or thread variable depending on the compilation options. It looks like you are using a thread-enabled php version with a non-thread enabled Informix build (esql -thread option). The Apache module and the CGI version are the only ones I can test. Please give me some more inforation, like your configure script. Danny --- ------------------------------------------------------------------------ [2000-09-18 00:40:38] [EMAIL PROTECTED] Setup: PHP 4.0.2 running under Netscape Enterprise 3.6SP1 on a Solaris 2.5.1/SPARC server. Informix-SE v7.23.UC9, Informix ESQL/C 7.24.UC7. My $INFORMIXDIR/etc/sqlhosts entry for the database looks like this: foo_se seipcpip foo sqlexec (which works under other langs) There are no non-default ifx.* entries in my php.ini file. After connecting to database foo, the first sql query fails consistently every other time, with SQLCODE -480. I get the following error: <b>Warning</b>: Allocate desciptor <descrpb> fails (E [SQLSTATE=IX 000 SQLCODE=-480]) in <b>/web/shtml/development/esd/unempins/emps.php</b> on line <b>275</b><br> Invalid query SELECT * FROM emps WHERE esdid=123456789 and the script quits. I looked up -480 and it means that a duplicate descriptor already exists. I'm closing all my db connections so I don't know why this is happening (I did read the prior bug report about when Zend really releases the resource). ------------------------------------------------------------------------ Edit this bug report at http://bugs.php.net/?id=6798&edit=1 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
