ID: 15198
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: OCI8 related
Operating System: Redhat Linux 6.1
PHP Version: 4.1.1
Assigned To: thies
Previous Comments:
------------------------------------------------------------------------
[2002-12-04 09:38:18] [EMAIL PROTECTED]
I've narrowed down a cause of this error to a lockwait on one or more
rows that a query is trying to modify. This is the simplest way to
reproduce:
1) in sqlplus: update table_name set column_2 = column_2_val where
column_1 = column_1_val; (do not commit)
2) run the same query from php
3) immediately run this query from another session (a client with a GUI
is best for viewing results of this query). Pay attention to the
lockwait column, it will not be null:
select
count(*) instances,
se.machine,
se.osuser,
sa.executions,
se.lockwait,
sa.sql_text
from
v$sqlarea sa,
v$session se
where
sa.address = se.sql_address
and
sa.hash_value = se.sql_hash_value
and
sa.executions > 0
and
se.status = 'ACTIVE'
group by
se.machine,
se.osuser,
sa.executions,
se.lockwait,
sa.sql_text
order by instances desc;
4) after a while your php script will come back with OCI8 Recursive
call!
5) don't forget to rollback your update in sqlplus!
This is the most simple scenario causing the bug. The problem also
happens on queries I use that operate (DML) on the same data and take a
while. Possible causes of this are users clicking multiple times on
links to pages that execute DML queries. However, sometimes I get this
error when there is only one query with a non-null lockwait value..
very strange.
I've tried registering shutdown functions and wrapping the queries that
most often produce this error with checks on connection_status() to
prevent running the query if user has abandoned the request. None of
these measures have helped the problem.
It's disturbing that the entire apache process has to die because of
this. Any suggestions are welome.
------------------------------------------------------------------------
[2002-04-13 09:07:32] [EMAIL PROTECTED]
No feedback was provided for this bug, so it is being suspended.
If you are able to provide the information that was requested,
please do so and change the status of the bug back to "Open".
if this itches you too badly you can just take out the exit(-1) call
from oci8.c and recompile. but it might kill your oracle MTS
------------------------------------------------------------------------
[2002-02-28 13:31:40] [EMAIL PROTECTED]
I've also got a PHP application that suffered from the OCI8 Recursive
call! error after an upgrade to PHP 4.1.1. It worked fine with PHP
4.0.x, but with 4.1.x it randomly chokes with that error. There is
nothing special going on. I'm not using bindings, I've just got
scripts that logon, parse, execute, insert, delete, logoff, etc.
Because of this, I'm forced to stick with the 4.0.x tree. I'd give you
more debugging information, but it is a deployed system and I don't
want to introduce the bugs into it.
------------------------------------------------------------------------
[2002-02-05 05:07:25] [EMAIL PROTECTED]
are you sure that you are not hitting the time_limit?
reverting to 4.0.6 is not a smartthimg (tm) to do as a recursive oci
call might kill your oracle MTS (if you
use it). that's the only reason this catch got implemented.
maybe useing ociinternaldebug(1) and sending me the output (and just
the output of the oci module) would
help.
------------------------------------------------------------------------
[2002-02-05 03:30:24] [EMAIL PROTECTED]
Well, I have investigated the situation a bit more:
I have a script which takes a long time (a maintenance script that runs
at night, using php cgi binary), so I have set set_time_limit(7200)
(which is two hours!)
In the script, there's a complex query that takes 3 minutes to run.
During this query, I get this OCI8 Recursive Call error and the script
fails, even though the time limit has not been reached yet. Is there
some internal timeout in the OCI calls? I now have to downgrade to
4.0.6 to prevent the problem.
------------------------------------------------------------------------
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/15198
--
Edit this bug report at http://bugs.php.net/?id=15198&edit=1
