Posted by Andy Hassall on 09/25/05 13:46

On Fri, 23 Sep 2005 20:55:40 -0400, John Cecere <rootusr@optonline.net> wrote:

>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:cvsread@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 ?

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_session.

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.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Back to original message]