RE: [PHP-DEV] R: [PHP-DEV] [PATCH] OCI8 module - proposed patches (PART 1 of 2)

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