|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #9496 Mixing non persistant and persistant connection makes all connexions persistant
Submitted: 2001-02-28 08:33 UTC Modified: 2003-12-28 22:00 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: jean-francois dot gosset at telintrans dot fr Assigned:
Status: No Feedback Package: OCI8 related
PHP Version: 4.0.4pl1 OS: linux red hat 6.2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: jean-francois dot gosset at telintrans dot fr
New email:
PHP Version: OS:


 [2001-02-28 08:33 UTC] jean-francois dot gosset at telintrans dot fr
With the following test (test_oci8.php) both connexions (USER_1 and USER_2) are persistant.

Notes :

1. We can see that connexions are persistant with the following SQL command :

  select username, status, logon_time from v$session where username='USER_1' or username='USER_2';
2. We can use the following workaround : use a different database name for USER_1 and USER_2 (who acces the same real database).

3. If we invert the order of connexions (USER_2 before USER_1) and use OCInlogon for USER_1, only USER_2 has persistant connexions but the number of connexions of USER_2 increase until to reach the maximum limit (ORA-00604 error).

<title>OCI8 bug test</title>

    $user = "USER_1";
    $password = "pwd1";
    $database = "TEST";

        // should be non persistent !!!!
        $connexion = OCIlogon (

        if (!$connexion)
            trigger_error (
                "Erreur OCIlogon $user / $database",
            echo "<p>Connexion 1 OK";

        OCIlogoff ($connexion);
        $user = "USER_2";
        $password = "pwd2";
        $database = "TEST";

        // If we use a different databasename (for the same real database) we don't have the problem
        // $database = "TEST2";

        $connexion = OCIplogon (

        if (!$connexion)
            trigger_error (
                "Erreur OCIplogon $user / $database",
            echo "<p>Connexion 2 OK";

        OCIlogoff ($connexion);



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2001-05-04 10:44 UTC]
OCIPlogon() will do the same as OCILogon() but mark the sever and session handle as persistent, which means that PHP won't close them on script-end. if your script does a OCILogon("s","t") and later a OCIPLogon("s","t") _no_ new server or session handle will be created but instead the existing ones will be marked persistent.

this is intended behaviour - why would we want to change it?

 [2001-06-15 03:53 UTC] jean-francois dot gosset at telintrans dot fr
I think this behaviour is confusing.

One can have the needs to mix persistant and non persistant connexion on the same database. In my case, I want to validate an account with a personal username and after use a generic account. The first one must not be persistant because we would have too much connexions open.

 [2002-04-13 08:18 UTC]
i still cannot see any problem. you approach would consume _more_ resourcs on the oracle server. anyhow this is not a bug.

 [2003-12-18 17:14 UTC] kamil at okac dot org
The behaviour is correct for the case when you call OCILogon('u1','p1') and OCIPLogon('u1','p1') (with the same user), but incorrect when you call OCILogon('u1','p1') and OCIPlogon('u2','p2'). The latter case creates two sessions (that's correct - can't be shared, because two different users are logging in), but both sessions are made persistent.
This happens even if OCIPlogon and OCILogon are not called within one script but handled by the same process.

Maybe the problem is in the reusing of persistent server connections (where usernames are not involved).
 [2003-12-19 02:29 UTC]
Could you, please, try it with latest CVS snapshots of PHP5 & PHP4?
This behaviour was changed in PHP5 recently.
 [2003-12-28 22:00 UTC]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

 [2004-01-03 17:18 UTC] kamil at okac dot org
The bug seems to be a duplicate of #22674.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 16 07:01:29 2024 UTC