Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:824
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 9 Apr 2003 18:26:08 +0200
Message-ID: <7410A5117CDC9C4CA07FBC870D65A50D111CEA@MAILBOX01.domus.ad.sogei.it>
Thread-Topic: [PHP-DEV] R: [PHP-DEV] [PATCH] OCI8 module - proposed patches (PART 1 of 2)
Thread-Index: AcL+iE9puGhAeydJQD+Qzn9pdu50OgAKu59Q
To: "Thies C. Arntzen" <thies@thiesos.org>
Cc: "Jani Taskinen" <sniper@iki.fi>, <internals@lists.php.net>,
   <maxim@maxim.cx>
Subject: RE: [PHP-DEV] R: [PHP-DEV] [PATCH] OCI8 module - proposed patches (PART 1 of 2)
From: msquillace@sogei.it ("SQUILLACE MASSIMO")

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]=20
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:
>=20
> In complex projects like the ones I follow it is difficult to force=20
> case consistency, even when the developers are told to centralize the=20
> logon phase in a single script.
>=20
> I routinely observe several persistent connections per process with=20
> the same userid, and cannot guess whether this is because of "test"=20
> scripts or worse, because the programmer isn't adhering to the=20
> development rules; in any case I cannot afford to deploy an=20
> application without knowing exactly the maximum number of open Oracle=20
> sessions needed - the Oracle people require this info as it affects=20
> 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!

>=20
> This is just to say I will nonetheless have to patch our internal=20
> 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.=20

    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=20
> firewall that appears to truncate idle persistent sessions in such a=20
> way that when a script running on an affected process executes the=20
> first OCI statement it doesn't immediately return with something like=20
> a 3113 error (end of file on communication channel), but rather blocks

> until Apache reaches its configured timeout (defaults to 300 seconds)=20
> - this is clearly unacceptable (same problem with sqlplus).

    this is something to ask oracle about.

>=20
> I'd certainly like PHP to automatically close idle connections to all=20
> kinds of databases, but to do so right it would have to periodically=20
> call specialized module-defined cleanup functions in any case=20
> (possibly also in between requests, when the Apache process is=20
> otherwise idle).

    remember that we live in a multi-process world. an httpd
    process won't call internal housekeeping functions by itself
    (while idle).

>=20
> Until then my proposed solution will help minimize Oracle outstanding=20
> connections, and maybe could be reused as a PHP called cleanup=20
> 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