RE: R: [PHP-DB] Persistent Oracle Login & Connection Loss Detection?
| From: | Florian Clever | Date: | Thu, 19 Oct 2000 18:07:17 +0000 |
| Subject: | RE: R: [PHP-DB] Persistent Oracle Login & Connection Loss Detection? | ||
| References: | 1 | Groups: | php.db |
| Request: | Send a blank email to php-db+get-3810@lists.php.net to get a copy of this message | ||
Yes that is exactly what I believe too.
-----Original Message-----
From: Roberto Sartor [mailto:roberto@mionetto.it]
Sent: Thursday, October 19, 2000 6:29 PM
To: 'Florian Clever'
Cc: 'PHP DB'
Subject: R: R: [PHP-DB] Persistent Oracle Login & Connection Loss
Detection?
1 thing is sure: there's no array for cycling and looking in for open
persistent connections towards Oracle and other RDBMS. It's impossible to
disconnect them without shutting down Web Server. Am I right?
Ciao
Roberto
> -----Messaggio originale-----
> Da: Florian Clever [mailto:clever@ukl.uni-freiburg.de]
> Inviato: mercoledì 18 ottobre 2000 16.09
> A: Roberto Sartor
> Oggetto: Re: R: [PHP-DB] Persistent Oracle Login & Connection Loss
> Detection?
>
>
> Putting a @ infront of OCIPLogon does not solve the Problem,
> because the
> actual connection is not established, so the script can not get any
> data.
> Shutting down the webserver is fine on a development server but on
> production it does not work. On Production PHP needs to be
> able to kill
> the broken Persitent connection and completely reestablish it.
>
> just my opinion,
> Florian
>
> Roberto Sartor schrieb:
> >
> > Try putting @ before OCIPLogon, or (if it doesn't run as
> you expected)
> > shutdown Web Server before Oracle and start it after Oracle
> comes up!!!
> > In my opinion, it means persistent connection to oracle
> should be fairly
> > closed. :)
> >
> > Ciao
> > Roberto
> >
> > > -----Messaggio originale-----
> > > Da: Florian Clever [mailto:clever@ukl.uni-freiburg.de]
> > > Inviato: mercoledì 18 ottobre 2000 8.04
> > > A: David Hubbard; php-db@lists.php.net
> > > Oggetto: [PHP-DB] Persistent Oracle Login & Connection
> Loss Detection?
> > >
> > >
> > > Hi,
> > >
> > > I am having the same problem on WinNT 4, SP6a, Oracle8i
> (Release 2),
> > > IIS4. I do get a slightly differnt text though. "Need
> explicit attach
> > > before connecting".
> > >
> > > Florian
> > >
> > > Original Message:
> > >
> > > Hi all, hopefully someone can help me with this peculiar
> > > problem. I have a large number of Oracle driven pages
> > > that all php require() an Oracle login file. In the file
> > > I use the standard OCIPLogon() command to establish a
> > > persistent connection to my 8.0.6 database server, I
> > > never call OCILogOff().
> > >
> > > This works wonderfully and I get persistent connections
> > > that are reused for all of my pages. The problem occurs
> > > when the Oracle server is rebooted. After that, all of
> > > my pages start showing:
> > >
> > > Warning: OCIStmtExecute: ORA-03114: not connected to
> > > ORACLE in
> > > /usr/local/apache/htdocs/product/show-status-table.php
> > > on line 14
> > >
> > > I tried to change my included login file to do
> > > something like:
> > >
> > > if ( ! ($dbConn = OCIPLogon(user, pass, DB)) ) {
> > > OCILogOff($dbConn);
> > > OCIPLogon(user, pass, DB);
> > > }
> > > else
> > > $dbConn = OCIPLogon(user, pass, DB);
> > >
> > > But that didn't work, and if or if not $dbConn doesn't
> > > work either. Does anyone have any ideas how I can detect
> > > this condition and automatically re-establish the
> > > connection? Typically the server will be reboot at night
> > > so I'd like the first person in the morning to have
> > > this code catch the problem and fix things, otherwise
> > > it stays broken until I restart apache. :-)
> > >
> > > Thanks,
> > >
> > > Dave
> > >
> > >
> > > # # #
> > >
> > > The information contained in this message, including any
> accompanying
> > > documents, is
> > > confidential and is intended for the addressee(s) only.
> If you have
> > > received this message in
> > > error or there are any problems, please notify the originator
> > > immediately. The unauthorized
> > > use, disclosure, copying or alteration of this message is strictly
> > > forbidden. For additional
> > > information about GTE TSI, please visit our website at
> > > http://www.tsi.gte.com.
> > >
>