ID: 15198 Comment by: jcarlos at wysiwyg dot net Reported By: ivo at ibuildings dot nl Status: No Feedback Bug Type: OCI8 related Operating System: Redhat Linux 6.1 PHP Version: 4.1.1 Assigned To: thies New Comment:
I had the same problem with Solaris+Apache server. Oracle crashed and the DBA rebooted it, but Apache kept opened Oracle connections. These connections was broken but Apache tried to query Oracle at the same time the new PHP connections did. The solution was rebooting Apache, and then all worked ok. PHP version is 4.3 Previous Comments: ------------------------------------------------------------------------ [2003-05-18 11:52:03] [EMAIL PROTECTED] And way too old php version.. ------------------------------------------------------------------------ [2003-05-11 08:41:47] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip ------------------------------------------------------------------------ [2002-12-04 09:38:18] ldixon at mail dot communityconnect dot com 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] smkelly at rooster dot creighton dot edu 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. ------------------------------------------------------------------------ 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
