php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #37130 oci_pconnect does not reuse resource within single script runtime
Submitted: 2006-04-18 21:31 UTC Modified: 2006-04-19 16:40 UTC
From: jabramson at wgen dot net Assigned:
Status: Not a bug Package: OCI8 related
PHP Version: 5.1.2 OS: Windows XP
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: jabramson at wgen dot net
New email:
PHP Version: OS:

 

 [2006-04-18 21:31 UTC] jabramson at wgen dot net
Description:
------------
- Apache/1.3.34 (Win32) PHP/5.1.2

- php_oci8.dll is latest build from PECL (dated 4/17/06) : $Revision: 1.293 $

- all related ini settings are default (i.e. no explicit oci8 directives)

according to php manual, non-persistent and persistent db connections should behave identically.

also according to the manual - this is specified under docs for oci_connect() - "The second and subsequent calls to oci_connect() with the same parameters will return the connection handle returned from the first call..."

i have found that oci_pconnect is creating a new connection handle for each invocation, whereas oci_connect behaves properly according to the docs.

Reproduce code:
---------------
<?php

assert_options(ASSERT_WARNING,1);

$cx = oci_connect("user","pass","db");
$cx2 = oci_connect("user","pass","db");

if (assert($cx==$cx2)) {
    print 'oci_connect behaves properly';
}


$pcx = oci_pconnect("user","pass","db");
$pcx2 = oci_pconnect("user","pass","db");

if (assert($pcx==$pcx2)) {
    print 'oci_pconnect behaves properly';
}

?>


Expected result:
----------------
EXPECTED: no warnings, the assertions pass.

Actual result:
--------------
ACTUAL: the oci_connect assertion passed, but the pconnect version does not.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-04-18 21:43 UTC] tony2001@php.net
Comparing resources with "==" doesn't make much sense, as they identificators may differ, but that doesn't mean underlying connections are not the same.
 [2006-04-19 16:01 UTC] jabramson at wgen dot net
OK, yes, it's understood I am merely comparing an identifier and not the resource itself.  Nevertheless this is a clear difference in behavior, no?  Is it by design?

Note that '===' test fails on those pconnect() resources as well (but passes on connect() ones).  Does it mean that, aside from querying oracle server for session info and comparing those results, there is no reliable identity test for pconnect() resources?
 [2006-04-19 16:20 UTC] tony2001@php.net
>Nevertheless this is a clear difference in behavior, no?
No

>Is it by design?
Sure it is.

>Does it mean that, aside from querying
>oracle server for session info and comparing those
> results, there is no reliable identity test for 
>pconnect() resources?

In common case - yes.
But you can try to do it manually in the same way OCI8 does:
looking at the parameters (login, password, db); persistent or not; and what character set is used.
Anyway, wth do you need it?
 [2006-04-19 16:40 UTC] jabramson at wgen dot net
The way i ran into the first place was a unit test where I need to assert that I *don't* have more than one actual connection in use (per set of logon credentials) at a time.    (My app does very tight oracle logging and connection/transaction control, so being able to manage and verify the true identity of connections is important.)

The test input is a set of Arrays, for example, each containing the user, oracle_sid, and the oci8 resource.  If i have more than one matching pair of user/oracle_sid, then I want to compare the resources and make sure they also point to the same connection.

Problem is it will always fail for the pconnects if those resources always get a new handle/id#. 

I can accept the behavior if it's by design, but still believe it's at odds with the documented functionality, and find it counter-intuitive as well.

Thx,
Jim
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Apr 28 00:01:28 2024 UTC