R: [PATCH] OCI8 module - proposed patches (PART 1 of 2)

Alright,

I will test the patch for a some time to assure that everything works fine
and the defaults remain defaults, after what I will commit it in. As of
php.ini, I do not have a karma for that, so will have to ask someone to
commit the changes for me.

Cheers,

Maxim Maletsky
maxim@php.net

SQUILLACE MASSIMO writes:

Thies,

Thank you for the constructive criticism, and for the open-mindedness of
allowing the changes nonetheless.
Rest assured the default behaviour will remain the same: I never wanted
anything different.

Maxim,

Will you please commit the "fourpatches.txt" diff file?
Who modifies the php.ini introducing the new [OCI8] section?

Regards,

Massimo

-----Original Message-----
From: Thies C. Arntzen [mailto:thies@thiesos.org]
Sent: Wednesday, April 09, 2003 12:01 PM
To: SQUILLACE MASSIMO
Cc: Thies C. Arntzen; Jani Taskinen; internals@lists.php.net
Subject: Re: [PHP-DEV] R: [PHP-DEV] [PATCH] OCI8 module - proposed
patches (PART 1 of 2)

In complex projects like the ones I follow it is difficult to force
case consistency, even when the developers are told to centralize the
logon phase in a single script.

I routinely observe several persistent connections per process with
the same userid, and cannot guess whether this is because of "test"
scripts or worse, because the programmer isn't adhering to the
development rules; in any case I cannot afford to deploy an
application without knowing exactly the maximum number of open Oracle
sessions needed - the Oracle people require this info as it affects
server configuration and hardware choice.

simple question:
are you sure that all oracle supported auth-methods are
case-insensitive? 

i don't have a real problem with the patch i just feel it is
completely unneeded! 

This is just to say I will nonetheless have to patch our internal
sources with this "non feature", if you decide not to commit my patch.

i have a hard time understanding why you cannot guarantee that
your developers use the _same_ connection data for their
db-logons.  

having said that - as long as the default stays unchanged i'm
"ok" to commit that stuff. 

Concerning the timeout feature, I currently have a problem with a
firewall that appears to truncate idle persistent sessions in such a
way that when a script running on an affected process executes the
first OCI statement it doesn't immediately return with something like
a 3113 error (end of file on communication channel), but rather blocks

until Apache reaches its configured timeout (defaults to 300 seconds)

• this is clearly unacceptable (same problem with sqlplus).

this is something to ask oracle about. 

I'd certainly like PHP to automatically close idle connections to all
kinds of databases, but to do so right it would have to periodically
call specialized module-defined cleanup functions in any case
(possibly also in between requests, when the Apache process is
otherwise idle).

remember that we live in a multi-process world. an httpd
process won't call internal housekeeping functions by itself
(while idle). 

Until then my proposed solution will help minimize Oracle outstanding
connections, and maybe could be reused as a PHP called cleanup
function if and when the time comes.

hmm, again i think your patch solves two problems at the
wrong spot - but if it helps you, go ahead and have maxim commit
it for you. BUT please make sure that the default-behaviour
stays the same and you tweaks have to be activated via
php.ini. 

one sidenote: my expirience with oracle is that it simply
doesn't like connections to be cut, and often you'll find,
that closing teh "cutted" connection will leave the oci-libs
in an unstable state. (that might have changed over the
years though). 

re,
tc