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.