ID: 22674 Updated by: [EMAIL PROTECTED] -Summary: Unexpected build-up of persistent connections Reported By: msquillace at sogei dot it Status: Open Bug Type: OCI8 related Operating System: Redhat 7.3 -PHP Version: 4.3.3RC4-dev +PHP Version: 4CVS, 5CVS New Comment:
I put the patch online: http://www.php.net/~jani/patches/bug22674.patch Previous Comments: ------------------------------------------------------------------------ [2003-12-06 07:44:43] msquillace at sogei dot it I have just built the diff against the current PHP_4_3 branch. The diff patches the bugs reported but doesn't include the user credentials' case conversion nor the timing-out mechanism I devised for persistent connections, since I understand that Thies Arntzen doesn't believe it is appropriate to include them in the maintained extension. I upgraded the code to use the new "smart_str" helper functions. I'll email the patch to [EMAIL PROTECTED], because I can't provide an URL to it right now: let me know if it reaches you. ------------------------------------------------------------------------ [2003-11-27 01:21:38] [EMAIL PROTECTED] Please provide an URL to your unified diff patch against latest PHP_4_3 CVS branch. ------------------------------------------------------------------------ [2003-04-16 03:27:48] msquillace at sogei dot it Fred, I have since submitted a patch to the OCI8 module that solves this problem, and am waiting for it to be committed. For further details you can follow the relevant thread in the php.internals mailing list starting with: http://news.php.net/article.php?group=php.internals&article=762 ------------------------------------------------------------------------ [2003-04-15 14:00:09] fred dot cohen at iridium dot com this setting in httpd.conf helps the problem considerably: MaxRequestsPerChild 100 I've seen situations where every apache process would have two oracle connections open. Trick seems to be to limit the life of the apache process. ------------------------------------------------------------------------ [2003-03-13 08:31:14] msquillace at sogei dot it Environment is Linux RedHat 7.3, Apache 1.3.27, PHP 4.3.1 DSO with OCI8 (8.1.7.0) and several other extensions; the Oracle database (8.1.7.3) is on a Win2k server. The described behaviour also shows in PHP 4.2.2 and PHP 4.2.3, and with Oracle 9i, and can be reproduced (I usually begin by starting Apache with the -X switch) e.g. with the following script: <?php OCIInternalDebug(1); $conn0 = OCIPLogon("user1","pwd1", "db1"); $conn1 = OCILogon("user2","pwd2", "db1"); //sleep(10); print "<pre>".OCIServerVersion($conn0)."<br>"; print OCIServerVersion($conn1)."</pre>"; ?> The number of outstanding Oracle sessions can be checked from sqlplus: select machine,process,username,status from v$session order by process; where "process" shows the PID of the Apache process executing the PHP script. I'd expect to see exactly one persistent session (for user1) associated with the single Apache process after running the script, but I observe two instead, one for each user. Running the same script again doesn't change the situation. There's more, though: if at this point I run a similar script where I've changed the OCILogon to OCINLogon, I observe the correct behaviour of (an additional) new session being first created for user2 then destroyed at script end, but when I subsequently re-run the original script (OCILogon), another persistent session for user2 appears! This leads to a persistent session build-up with Oracle eventually complaining for too many sessions. As a side (but important) note, I observed that while Oracle is case-insensitive with regard to the user credentials and the db alias used in a connection, the OCI8 extension is case-sensitive: if I make two OCIPLogon(s) whose arguments differ only in case I get two persistent Oracle sessions. I'd suggest converting the (left- and right-trimmed) arguments to upper or lower case in the extension before checking for reusability against already existing sessions. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=22674&edit=1
