Re: R: [PHP-DEV] [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) On Wed, Apr 09, 2003 at 12:19:33PM +0200, SQUILLACE MASSIMO wrote:

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