Bug #74223 [Opn]: db2 table locks during commit after hitting max_execution_time

Edit report at https://bugs.php.net/bug.php?id=74223&edit=1 ID: 74223 Updated by: nikic@php.net Reported by: giacomo dot fontanella at carige dot it Summary: db2 table locks during commit after hitting max_execution_time Status: Open Type: Bug Package: PDO ODBC Operating System: windows server 2008 R2 PHP Version: 5.6.30 Block user comment: N Private report: N New Comment: I'd also be interested in knowing if this issue still reproduces on PHP 7.1. I have no familiarity with ODBC or DB2, but depending on the specific reasons of why this happens, the timeout handling changes in PHP 7.1 may have fixed this already. Timeouts will no longer interrupt internal function calls -- either it will wait until the call is finished, or it will kill the process entirely. Previous Comments: ------------------------------------------------------------------------ [2018-01-05 13:00:28] spam2 at rhsoft dot net > with different versions of PHP from 5.3 to 5.6 but in Linux server what about try and report back with some *supported* version of PHP (7.1.x/7.2.x) especially for a niche like db2 stuff not that widely used combined with PHP ------------------------------------------------------------------------ [2018-01-05 12:53:57] j_a_v_i at hotmail dot com Same problem here. We have been facing this issue during years with different versions of PHP from 5.3 to 5.6 but in Linux server. The only solution we found is killing the server each time it happens and to create scripts to kill process when they detect that happening. Any chance this be solved? ------------------------------------------------------------------------ [2017-03-08 10:14:41] spam2 at rhsoft dot net > PHP: 5.6.30 > Seems similar to bug #63576, reported for php 5.3.16 PHP 5.6 is as you should know EOL and won't get any updates except high critial security patches ------------------------------------------------------------------------ [2017-03-08 10:04:20] giacomo dot fontanella at carige dot it Description: ------------ Any script invoked through an Apache webserver that includes odbc calls to a IBM db2 database leaves an open application on it if max_execution_timeout is reached. This can lead to db locks impossible to resolve, unless either you kill the hanging process on db2 or you restart the webserver service. For example, a Reorg operation that should take just few seconds wouldn't start unless the hanging process is resolved. Seems similar to bug #63576, reported for php 5.3.16. My configuration is as follows: WEBSERVER OS: Windows server 2008 R2 webserver: Apache 2.4.23, VC11 compiler PHP: 5.6.30, MSVC11 compiler DBSERVER OS: Windows server 2008 R2 database: IBM DB2 9.7.8 Test script: --------------- <?php set_time_limit (1); include("../gestione_connessione.php"); $i = 0; while(1){ $rs = odbc_exec($cn,"SELECT COUNT(*) as N_RECORD FROM DBTEST.TB_TEST"); echo "<br>".$i." ".odbc_result($rs,"N_RECORD"); $i++; } ?> Expected result: ---------------- Loading halted after 1 second, no after effects. Actual result: -------------- Loading halted after 1 second, this is the error in log file: [Wed Mar 08 10:13:32.744279 2017] [:error] [pid 4872:tid 2064] [client xx.xx.xx.xx:62549] PHP Fatal error: Maximum execution time of 1 second exceeded in [PATH]\\test_lock.php on line 8 On the db2 server remains a httpd.exe application in UOW waiting status: (taken from db2 monitor) ID: 7679 Application name: httpd.exe OS user: [Account assigned to apache service] DB user: [db2 user] Status: UOW witing Last operation: SQL fetch DB: [db instance] Connect time: 08/03/2017 10.13.33 This application hangs indefinitely; if I launch a REORG on DBTEST.TB_TEST, this is what I get from the db2 monitor for the related process: ID: 7712 Application name: db2bp.exe OS user: [admin account] DB user: [admin account] Status: Lock wait Last operation: Reorg DB: [db instance] Connect Time: 08/03/2017 10.51.08 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=74223&edit=1