Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:825 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71792 invoked from network); 9 Apr 2003 17:09:59 -0000 Received: from unknown (HELO ianwh.ian.cx) (218.45.162.227) by pb1.pair.com with SMTP; 9 Apr 2003 17:09:59 -0000 Received: (qmail 4063 invoked by uid 352); 9 Apr 2003 17:09:57 -0000 Message-ID: <20030409170957.4062.qmail@ianwh.ian.cx> References: <7410A5117CDC9C4CA07FBC870D65A50D111CEA@MAILBOX01.domus.ad.sogei.it> In-Reply-To: <7410A5117CDC9C4CA07FBC870D65A50D111CEA@MAILBOX01.domus.ad.sogei.it> To: "SQUILLACE MASSIMO" Cc: "Thies C. Arntzen" , "Jani Taskinen" , internals@lists.php.net Date: Thu, 10 Apr 2003 02:09:57 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: R: [PHP-DEV] [PATCH] OCI8 module - proposed patches (PART 1 of 2) From: maxim@maxim.cx ("Maxim Maletsky") Alright, I will test the patch for a some time to assure that everything works fine and the defaults remain defaults, after what I will commit it in. As of php.ini, I do not have a karma for that, so will have to ask someone to commit the changes for me. Cheers, Maxim Maletsky maxim@php.net SQUILLACE MASSIMO writes: > 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