Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:820
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Wed, 9 Apr 2003 13:00:55 +0200
To: SQUILLACE MASSIMO <msquillace@sogei.it>
Cc: "Thies C. Arntzen" <thies@thiesos.org>,
	Jani Taskinen <sniper@iki.fi>, internals@lists.php.net
Message-ID: <20030409110055.GB7973@schnuffel.thieso.net>
References: <7410A5117CDC9C4CA07FBC870D65A50D111CE9@MAILBOX01.domus.ad.sogei.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <7410A5117CDC9C4CA07FBC870D65A50D111CE9@MAILBOX01.domus.ad.sogei.it>
User-Agent: Mutt/1.4i
Subject: Re: [PHP-DEV] R: [PHP-DEV] [PATCH] OCI8 module - proposed patches (PART 1 of 2)
From: thies@thiesos.org ("Thies C. Arntzen")

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