ID: 30808
Comment by: gid at gifpaste dot net
Reported By: michael dot caplan at lechateau dot ca
Status: Suspended
Bug Type: OCI8 related
Operating System: RHE 3
PHP Version: 5.0.2
Assigned To: tony2001
New Comment:
Our development database server also goes down every night for a cold
back up so we get this error every morning in development. (our
production server however is always up)
This is rather disturbing that this is happening even when using
ocinlogon. If I want to create a new connection to oracle, then php
should trust that I, the programmer know what I am doing. Maybe put a
note in the manual stating that ocinlogon should ONLY be used after
ocilogon or ociplogon fails.
Maybe it's me, but this ini setting seems like a hack to me. If an
oracle connection gets in a corrupted state, then I should be able to
detect the bad oracle connection, close it, and try opening a new
connection all in php code. Just because someone takes their database
server down every night doesn't mean they should have to pay the
penalty of oci_ping on every connection.
Previous Comments:
------------------------------------------------------------------------
[2004-11-19 14:20:25] michael dot caplan at lechateau dot ca
FYI, I am using a DB abstraction library (PEAR::MDB2), and just
realized for non persistant connections it is using ociNlogon() for non
persistant connections. So, to revise my original report, it is not
just ociplogon() that is affected, but also ociNlogon() as well. This
certainly does put a new spin on things and perhaps warrants
unsuspending this bug report.
------------------------------------------------------------------------
[2004-11-19 10:14:06] giunta dot gaetano at sea-aeroportimilano dot it
It is very funny that I never experienced this problem, given the
really heavy usage we do of PHP+Oci at work. But then I stick with php
4 for now: does this bug also apply to the 'old' version?
Anyway, here's what I generally do, both in C++ OCI sw and php scripts
that run as services (ie never-ending): 1) connect to db 2) exec query
3) if query fails the close and reopen connection 4) goto 2
In this usage pattern the PHP connection to Oracle is not persistent
(it is kept open by the script anyway). And the scripts have been
chugging away for years thru network outages, DB upgrades and all.
I wonder if a similar pattern could solve your problem in a PHP as
Apache module situation: let the app layer do the actual 'pinging' of
the DB instead of tho oci layer (eg try to close and reopen pending db
connections when something fails...)
------------------------------------------------------------------------
[2004-11-18 22:53:42] [EMAIL PROTECTED]
Nope, mysql_connect() reconnects every time, as ociNlogon() does, so it
does not need to ping server.
ocilogon(), however, doesn't "reconnect" on every request, as this
operation in Oracle is rather slow, comparing with MySQL (you could try
to compare ociNlogon() vs ocilogon() speed and see the difference).
instead, it only creates new session, but server connection is stored
persistently and this causes your problem.
------------------------------------------------------------------------
[2004-11-18 17:59:18] michael dot caplan at lechateau dot ca
hi tony,
how does the mysql connect function handle this problem, or does it
ping the server each time?
------------------------------------------------------------------------
[2004-11-18 17:54:04] [EMAIL PROTECTED]
>And I don't see why a solution would necessarily depend on
pre-pinging.
I'd be glad to hear your proposal, Patrick.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/30808
--
Edit this bug report at http://bugs.php.net/?id=30808&edit=1
