PHP :: Bug #74223 :: db2 table locks during commit after hitting max_execution_time
php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #74223 db2 table locks during commit after hitting max_execution_time
Submitted: 2017-03-08 10:04 UTC Modified: 2018-01-05 13:05 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: giacomo dot fontanella at carige dot it Assigned:
Status: Open Package: PDO ODBC
PHP Version: 5.6.30 OS: windows server 2008 R2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: giacomo dot fontanella at carige dot it
New email:
PHP Version: OS:

 

 [2017-03-08 10:04 UTC] 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


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-03-08 10:14 UTC] 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
 [2018-01-05 12:53 UTC] 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?
 [2018-01-05 13:00 UTC] 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 13:05 UTC] nikic@php.net
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.
 
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Tue Aug 14 06:01:25 2018 UTC