Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:819
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 12:19:33 +0200
Message-ID: <7410A5117CDC9C4CA07FBC870D65A50D111CE9@MAILBOX01.domus.ad.sogei.it>
Thread-Topic: [PHP-DEV] R: [PHP-DEV] [PATCH] OCI8 module - proposed patches (PART 1 of 2)
Thread-Index: AcL+aJ2qFpL3zd9VSNG9BC60PTXbSAAEOXzQ
To: "Thies C. Arntzen" <thies@thiesos.org>
Cc: "Jani Taskinen" <sniper@iki.fi>, <internals@lists.php.net>
Subject: RE: [PHP-DEV] R: [PHP-DEV] [PATCH] OCI8 module - proposed patches (PART 1 of 2)
From: msquillace@sogei.it ("SQUILLACE MASSIMO")

Well, I was ready for critiques re: the uppercase "feature", and I can
understand (and personally approve) your line of thought.

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.

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.

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).

Furthermore, the TNS failover solution (you give sound advice, and I
recall reading it in your answer to a bug) is not always viable: we are
building an application using RAC (Oracle9i Realtime Application
Cluster) with two separate back-end servers running the Oracle instances
(and several load-balanced front-end web servers in a DMZ), and already
need the TNS failover to switch between instances when one of them
happens to be down.

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).

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.

Regards,

Massimo

-----Original Message-----
From: Thies C. Arntzen [mailto:thies@thiesos.org]=20
Sent: Wednesday, April 09, 2003 8:21 AM
To: SQUILLACE MASSIMO
Cc: Jani Taskinen; internals@lists.php.net
Subject: Re: [PHP-DEV] R: [PHP-DEV] [PATCH] OCI8 module - proposed
patches (PART 1 of 2)


   =20
    okay, here are some comments.

    i think you are right that the current oci has a bug with
    persitent connections. (likely to be fixed by your patch - just
commit that
    part)


    but i have a problem with the 2 new features:

    i don't think that timing out persistent connections should
    be done in oci8.c. _if_ we decide that PHP should automatic
    close unused persistent connections i really think we should
    find a more general solution that will work for all kinds of
    persistent connections.

    to solve your firewall-kills-idle-oracle-connections problem
    just configure a TNS failover to the same oracle instance in
    tnsnames.ora: (something down the lines)

failover =3D
  (DESCRIPTION =3D
    (ADDRESS =3D (PROTOCOL=3D TCP)(Host=3D 127.0.0.1)(Port=3D 1521))
    (CONNECT_DATA =3D (SID=3DDC4)
(failover_mode=3D(backup=3Dfailover)(type=3Dsession)(method=3Dbasic)(retr=
y=3D100)(
delay=3D60)))
  )

    re the uppercasing of oracle-credentials: even if -no matter what
    authentication method you use- all oracle credentials are case=20
    insensitive today, can you guarantee they will be tomorrow?=20
    i think this patch adresses a problem that does not exist. if=20
    ppls do ociplogin("scott","tiger") and later
ociplogon("SCOTT","TIGER")
    they *deserve* do waste one persistent connection:-) also note that
the
    *same* "problem" exists in all other php db-drivers AFAICS.

    regards,
    tc