From:             [EMAIL PROTECTED]
Operating system: Linux 2.2
PHP version:      4.2.2
PHP Bug Type:     OCI8 related
Bug description:  Php Warning: 'OCI8 Recursive call!'

This error is referenced in a closed bug (Bug #15198) which I was unable to
get a response from.  I have more information on it, and am seeking
alternative handling other than having the apache process completely
exit().

-----

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.
-- 
Edit bug report at http://bugs.php.net/?id=21203&edit=1
-- 
Try a CVS snapshot:         http://bugs.php.net/fix.php?id=21203&r=trysnapshot
Fixed in CVS:               http://bugs.php.net/fix.php?id=21203&r=fixedcvs
Fixed in release:           http://bugs.php.net/fix.php?id=21203&r=alreadyfixed
Need backtrace:             http://bugs.php.net/fix.php?id=21203&r=needtrace
Try newer version:          http://bugs.php.net/fix.php?id=21203&r=oldversion
Not developer issue:        http://bugs.php.net/fix.php?id=21203&r=support
Expected behavior:          http://bugs.php.net/fix.php?id=21203&r=notwrong
Not enough info:            http://bugs.php.net/fix.php?id=21203&r=notenoughinfo
Submitted twice:            http://bugs.php.net/fix.php?id=21203&r=submittedtwice
register_globals:           http://bugs.php.net/fix.php?id=21203&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21203&r=php3
Daylight Savings:           http://bugs.php.net/fix.php?id=21203&r=dst
IIS Stability:              http://bugs.php.net/fix.php?id=21203&r=isapi

Reply via email to