oci_close bug

[John Cecere]

I've run into this bug:

http://bugs.php.net/bug.php?id=29902

I'm beside myself trying to get around this. My application is dying after processing 20 transactions because there is no way to
close the connection. I've tried downloading and building the latest 5.1 CVS source via

cvs -d :pserver:cvsrea d@cvs.php.net:/repository checkout -r PHP_5_1 php-src

But this didn't help. The oci_close still always fails.

I have no control over the Oracle database to increase the number of sessions, nor am I likely to convince the DB admin to do so,
nor do I think this is a good idea anyway.

Does anybody have any ideas for a reasonable workaround to this ? I'm a little baffled as to why the latest source didn't fix the
problem. It was announced on 9/7 that the fix was in the CVS source. This is a little disappointing to say the least. We've been
building this app for over 4 months, and only now do we realize that we can't really do the Oracle part that we wanted to.

Any ideas ?

Thanks,
John

[Mladen Gogala]

Re: oci_close bug

On Fri, 23 Sep 2005 20:55:40 -0400, John Cecere wrote:
[color=blue]
>
> Does anybody have any ideas for a reasonable workaround to this ? I'm a little baffled as to why the latest source didn't fix the
> problem. It was announced on 9/7 that the fix was in the CVS source. This is a little disappointing to say the least. We've been
> building this app for over 4 months, and only now do we realize that we can't really do the Oracle part that we wanted to.
>
> Any ideas ?
>
> Thanks,
> John[/color]

The problem is allegedly fixed in Zend Core for Oracle, but it is for
certified platforms only (Suse & RH).

--

http://www.mgogala.com

[Andy Hassall]

Re: oci_close bug

On Sun, 25 Sep 2005 04:48:32 GMT, Mladen Gogala <gogala@sbcglob al.net> wrote:
[color=blue]
>On Fri, 23 Sep 2005 20:55:40 -0400, John Cecere wrote:
>[color=green]
>> Does anybody have any ideas for a reasonable workaround to this ? I'm a little baffled as to why the latest source didn't fix the
>> problem. It was announced on 9/7 that the fix was in the CVS source. This is a little disappointing to say the least. We've been
>> building this app for over 4 months, and only now do we realize that we can't really do the Oracle part that we wanted to.[/color]
>
>The problem is allegedly fixed in Zend Core for Oracle, but it is for
>certified platforms only (Suse & RH).[/color]

The Oracle-related changes in PHP included in Zend Core for Oracle are, if I
understand correctly, basically just in the new OCI8 driver. This is being
released back into the core distribution when it's stable, and is already
available separately through PECL in beta status:

http://pecl.php.net/package/oci8

--
Andy Hassall :: andy@andyh.co.u k :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Andy Hassall]

Re: oci_close bug

On Fri, 23 Sep 2005 20:55:40 -0400, John Cecere <rootusr@optonl ine.net> wrote:
[color=blue]
>I've run into this bug:
>
>http://bugs.php.net/bug.php?id=29902
>
>I'm beside myself trying to get around this. My application is dying after processing 20 transactions because there is no way to
>close the connection. I've tried downloading and building the latest 5.1 CVS source via
>
>cvs -d :pserver:cvsrea d@cvs.php.net:/repository checkout -r PHP_5_1 php-src
>
>But this didn't help. The oci_close still always fails.
>
>I have no control over the Oracle database to increase the number of sessions, nor am I likely to convince the DB admin to do so,
>nor do I think this is a good idea anyway.
>
>Does anybody have any ideas for a reasonable workaround to this ? I'm a little baffled as to why the latest source didn't fix the
>problem. It was announced on 9/7 that the fix was in the CVS source. This is a little disappointing to say the least. We've been
>building this app for over 4 months, and only now do we realize that we can't really do the Oracle part that we wanted to.
>
>Any ideas ?[/color]

What sort of connect are you using? Normal, new or persistent?
(ocilogon/oci_connect, ocinlogon/oci_new_connect , ociplogon/oci_pconnect)?

oci_close is a no-op, but sessions do get closed at end of request, at least
in my experience, and backed up by the comments in the source code in
ext/oci8/oci8.c and the call to OCISessionEnd in _oci_close_sess ion.

If you're using persistent connections, then you have to watch out for and/or
limit the number of Apache child processes, since the connection pool is
per-process.
--
Andy Hassall :: andy@andyh.co.u k :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Mladen Gogala]

Re: oci_close bug

On Sun, 25 Sep 2005 11:26:03 +0100, Andy Hassall wrote:
[color=blue]
> The Oracle-related changes in PHP included in Zend Core for Oracle are, if I
> understand correctly, basically just in the new OCI8 driver. This is being
> released back into the core distribution when it's stable, and is already
> available separately through PECL in beta status:
>
> http://pecl.php.net/package/oci8[/color]

The latest PECL oci8 extension doesn't work with PHP 5.1.0RC1. Here is
what I get when I run it with "extension=oci8 .so":

[Sun Sep 25 12:07:38 2005] [notice] child pid 28695 exit signal Segmentation fault (11)

When I disable it, it runs fine. I linked PHP with the extension that
comes with PHP5.1 (--with-oci8=$ORACLE_HO ME) and it works.


Did you play with PDO_OCI? I am disappointed by the fact that it cannot
describe a cursor. The following little program fails: $ cat test_pdo.php
#!/usr/local/bin/php <?php
$SQL1="select * from emp where ename like :ENAME"; $name='%'; try {
$dbh = new PDO("oci:dbname =local", "scott", "tiger");
$sth=$dbh->prepare($SQL1) ;
$sth->bindParam(":EN AME",$name,PDO_ PARAM_STR,100);
$sth->execute();
$cnt=$sth->columnCount( );
echo "This statement returns ",$cnt, " columns\n";
for($i=0;$i<$cn t;$i++) {
print_r($sth->getColumnMeta( $i));
print("\n");
}

} catch (PDOException $e) {
echo "Failed to obtain database handle " . $e->getMessage()," <br>\n";
}
?>

Here is what happens:
$ ./test_pdo.php
This statement returns 8 columns
PHP Warning: PDOStatement::g etColumnMeta(): SQLSTATE[IM001]: Driver does not support this function: driver doesn't support meta data in /home/mgogala/tmp/test_pdo.php on line 13

PHP Warning: PDOStatement::g etColumnMeta(): SQLSTATE[IM001]: Driver does not support this function: driver doesn't support meta data in /home/mgogala/tmp/test_pdo.php on line 13

PHP Warning: PDOStatement::g etColumnMeta(): SQLSTATE[IM001]: Driver does not support this function: driver doesn't support meta data in /home/mgogala/tmp/test_pdo.php on line 13

PHP Warning: PDOStatement::g etColumnMeta(): SQLSTATE[IM001]: Driver does not support this function: driver doesn't support meta data in /home/mgogala/tmp/test_pdo.php on line 13

PHP Warning: PDOStatement::g etColumnMeta(): SQLSTATE[IM001]: Driver does not support this function: driver doesn't support meta data in /home/mgogala/tmp/test_pdo.php on line 13

PHP Warning: PDOStatement::g etColumnMeta(): SQLSTATE[IM001]: Driver does not support this function: driver doesn't support meta data in /home/mgogala/tmp/test_pdo.php on line 13

PHP Warning: PDOStatement::g etColumnMeta(): SQLSTATE[IM001]: Driver does not support this function: driver doesn't support meta data in /home/mgogala/tmp/test_pdo.php on line 13

PHP Warning: PDOStatement::g etColumnMeta(): SQLSTATE[IM001]: Driver does not support this function: driver doesn't support meta data in /home/mgogala/tmp/test_pdo.php on line 13


Basically, what is says is that driver doesn't support returning column
name, type, length, scale an precision for returned column in a query.
That functionality is, of course, available in the existing OCI8 driver.

--

http://www.mgogala.com