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]
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)
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 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL= TCP)(Host= 127.0.0.1)(Port= 1521))
(CONNECT_DATA = (SID=DC4)
(failover_mode=(backup=failover)(type=session)(method=basic)(retry=100)(
delay=60)))
)
re the uppercasing of oracle-credentials: even if -no matter what
authentication method you use- all oracle credentials are case
insensitive today, can you guarantee they will be tomorrow?
i think this patch adresses a problem that does not exist. if
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
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