Re: Bug #15390: Persistent OCI8 Connections Get Poisoned

From: Date: Wed, 06 Feb 2002 09:51:35 +0000
Subject: Re: Bug #15390: Persistent OCI8 Connections Get Poisoned
References: 1 2  Groups: php.dev 
Request: Send a blank email to php-dev+get-79325@lists.php.net to get a copy of this message
On Tue, Feb 05, 2002 at 09:10:57PM -0500, George Schlossnagle wrote: > Isn't there handling for this in current cvs code? I remember > submitting a patch for this (and assoicated problems) to Thies, and it > being accepted. there is - but there seem to be some error-codes missing. george, you run a big PHP-oracle site if i recall right - ist it working to your satisfaction? tc > > George > > On Tuesday, February 5, 2002, at 04:23 PM, Hans Zaunere wrote: > > > >   > > Good idea (for the situation anyway).  It works.  I have all custom > > error handlers anyway, so when I detect a ORA-03313 error, I kill > > the current process with a SIGTERM.  Since I use header() to > > redirect to the error page, sometimes I get a blank page, but > > atleast when the database comes back, the whole system is back. > > Although PHP should handle this better in some manner.  :) > > > > Thank you, > > > > Hans > > > > mlwmohawk@mohawksoft.com wrote: > > > > We are seeing this problem too. I am thinking of having a standard > > error > > page which executes > > > > posix_kill ( pos_getpid()) ; > > > > On Oracle errors. > > > > > From:             hz11@nyu.edu > > > Operating system: RedHat 6.2 > > > PHP version:      4.0.6 > > > PHP Bug Type:     OCI8 related > > > Bug description:  Persistent OCI8 Connections Get Poisoned > > > > > > I have PHP 4.0.6 compiled as an Apache 1.3.20 module with OCI8 > > and > > > MySQL on RedHat 6.2.  I use persistent connections with OCI8 to > > avoid > > > the costly connection construction for Oracle for each request. > > > However, I notice that these persistent connections get > > "poisoned" > > > under certain > > > circumstances.  What I mean by this is this: > > > > > > Since each persistent connection stays with it's corresponding > > Apache > > > process, if the database happens to be down when a request comes > > in, > > > the persistent connection that is used throws an ORA-03113.  > > However, > > > even when the database comes back, the persistent connection > > still > > > thinks the database is down somehow, and will continue to throw > > the > > > ORA-03113 error.  As a result, if a request happens to hit the > > poisoned > > > Apache process, it appears the database is down.  If a request > > hits > > > another Apache process, all is OK. > > > > > > So far, the only way I've seen to deal this is to restart Apache, > > and > > > have the persistent connections build up again.  Obviously, this > > is not > > > a good thing, and if database connectivity is lost in any form, > > the > > > persistent connections get poisoned again, and the cycle begins. > > > > > > Now as this might not be a bug per se, I would think that > > persistent > > > connections should at least check that they aren't corrupted in > > some > > > way; or 'freshen' themselves.  Although I haven't tested it > > fully, I > > > have never seen this behavior with persistent MySQL connections. > > > > > > Please contact me for any further details or clarification if > > needed. > > > > > > Thank you, > > > > > > Hans > > > -- > > > Edit bug report at > > > http://bugs.php.net/?id=15390&edit=1 > > > -- > > > Fixed in CVS:        > > http://bugs.php.net/fix.php?id=15390&r=fixedcvs > > > Fixed in release: > > > > > > http://bugs.php.net/fix.php?id=15390&r=alreadyfixed Need > > backtrace: > > >  > > >http://bugs.php.net/fix.php?id=15390&r=needtrace Try newer > > version: > > > http://bugs.php.net/fix.php?id=15390&r=oldversion > > > Not developer > > issue: > > > http://bugs.php.net/fix.php?id=15390&r=support > > > Expected behavior: > > > http://bugs.php.net/fix.php?id=15390&r=notwrong > > > Not enough info: > > > > > > http://bugs.php.net/fix.php?id=15390&r=notenoughinfo > > > > > > > > > -- > > > PHP Development Mailing List > > > <http://www.php.net/> > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > // George Schlossnagle > // 1024D/1100A5A0  1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 > >

« previous php.dev (#79325) next »