|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66528 No PDOException or errorCode if database becomes unavailable before PDO::commit
Submitted: 2014-01-21 10:09 UTC Modified: -
Avg. Score:4.7 ± 0.7
Reproduced:36 of 41 (87.8%)
Same Version:11 (30.6%)
Same OS:11 (30.6%)
From: fk at florian-kaiser dot net Assigned:
Status: Open Package: PDO MySQL
PHP Version: 5.5.8 OS: Debian Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
41 + 45 = ?
Subscribe to this entry?

 [2014-01-21 10:09 UTC] fk at florian-kaiser dot net
If the database resource (e.g. the MySQL-Server) becomes unavailable before a PDO::commit(), it emits a warning only, e.g. "MySQL server has gone away" or "Error reading result set's header" and code execution proceeds.

Additionally, neither PDO::errorCode() nor PDO::errorInfo() are set. Inspected just after the warnings both suggest that everything is perfectly fine. This is unacceptable.

I dont really like the handling of that situation at all. Since warnings will only get logged in production mode and code execution proceeds without knowing there actually was an error (happens with PDO::commit() that returns true regardless), this will for sure give some developer lots of headaches. Together with that other bug in PDO::commit(), current implementation makes it _impossible_ to reliably check if a PDO::commit() call failed.

Please note that using PDO::query('commit'); instead of PDO::commit() actually respects PDO::ATTR_ERRMODE and behaves in a more proper way, e.g. if set to PDO::ERRMODE_EXCEPTION actually throws a PDOException and PDO::errorCode/errorInfo will be set accordingly. Warnings though will show regardless (when you're on it, fix that as well, please).
This is the only workaround in current implementations to reliably use transactions with PDOMysql.

A severe interruption like connection loss to database should be treated with the same error handling that is used when establishing the connection. Better still, just do it like PDO::query, honor PDO::ATTR_ERRMODE or throw a PDOException per default. No matter what will be implemented, PDO::errorCode and PDO::errorInfo must be fixed so they reflect errors that occur when using PDO::commit().

Test script:
$dbh = new PDO('mysql:dbname=test;host=;charset=UTF8', 'testuser', '');

// prepare table for test
$dbh->query('DROP TABLE IF EXISTS importantdata');
$dbh->query('create table test.importantdata (a int) engine=innodb');

try {

	$dbh->query('insert into importantdata (a) VALUES (1), (2)');

	sleep(20); // shut down mysql-server

} catch (PDOException $e) {
echo 'I should never get here';

Expected result:
"SQLSTATE[HY000]: General error: 2006 MySQL server has gone away" 
[... Script execution stopped]

Actual result:
Warning: PDO::commit(): MySQL server has gone away in /tmp/test.php on line 16

Warning: PDO::commit(): Error reading result set's header in /tmp/test.php on line 16
    [0] => 00000
    [1] => 
    [2] => 

I should never get here
[... Script execution proceeds]


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-07-20 21:05 UTC] fk at florian-kaiser dot net
It's now over 3 years since my initial bug report. Bug is still present in latest PHP7.1 making it _impossible_ to use PDO::commit() in a reliable fashion.

I really don't understand why a bug this severe is being kept open this long. It would really help us developers if this gets fixed soon.
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Tue Dec 11 15:01:25 2018 UTC