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
