Req #62065 [Com]: PDO should have a disconnect method

From: Date: Wed, 11 Mar 2015 17:01:00 +0000
Subject: Req #62065 [Com]: PDO should have a disconnect method
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-191317@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=62065&edit=1 ID: 62065 Comment by: bpolaszek at gmail dot com Reported by: b12 at bsdpower dot com Summary: PDO should have a disconnect method Status: Assigned Type: Feature/Change Request Package: PDO related Operating System: Any PHP Version: 5.3.13 Assigned To: willfitch Block user comment: N Private report: N New Comment: Hello, Actually unset($pdo) or $pdo = null works well as soon as there aren't any PDOStatement object initialized somewhere. When working on prepared statements, unsetting the PDO instance has the following behaviour : $pdo = new PDO([...]); $stmt = $pdo->prepare("SELECT * FROM mytable WHERE mycolumn = :myvalue"); $stmt->bindValue(':myvalue', 'oh hi'); $stmt->execute(); $myvalue = $stmt->fetch(PDO::FETCH_COLUMN); unset($myvalue); // $myvalue == null unset($stmt); // $stmt == null unset($pdo); // $pdo == null sleep(30); // for 30 seconds, I can see the PDO connection is still alive on my MySql server, despite $pdo is null. This wouldn't happen if I didn't prepare a statement. Tested on PHP 5.3, PHP 5.4, PHP 5.5. Do you plan a fix for this ? To avoid hundreds of sleeping connections while parsing big files, PHP should really disconnect from the database when asked to. Previous Comments: ------------------------------------------------------------------------ [2014-01-19 00:51:42] willfitch@php.net Updated wrong ticket. My apologies. I am still looking into this. ------------------------------------------------------------------------ [2014-01-19 00:50:49] willfitch@php.net The fix for this bug has been committed. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. This will be available in the next releases of PHP 5 ------------------------------------------------------------------------ [2014-01-10 03:44:41] willfitch@php.net I want to also note that any close/disconnect functionality will not affect persistent connectivity. ------------------------------------------------------------------------ [2014-01-10 03:23:03] willfitch@php.net This is really semantics, but I agree. The current documented approach (http://www.php.net/manual/en/pdo.connections.php) is to set the connection variable to null, which isn't elegant, but in reality, is no different than a method call: $dbh->close(); vs. $dbh = null; Both would achieve the same thing, but one is more attractive than the other. I'll look into adding a close/disconnect method and implement on existing drivers. ------------------------------------------------------------------------ [2013-02-07 10:35:26] ionut dot stan at hostway dot ro On a billing application the recurring services run on separate and consecutive transactions, so in case one fails with error the others are not blocked. At some point an error did occur (sooner or later it has to happen) - some data anomaly caused by some upgrade which didn't consider some scenario, and the application throws when it catches it. The uncommited transaction for the PDO object which will not be commited because of some assertion failure (app specific, not PDO related) was deadlocking future transactions. It would be nice if the PDO object could be disconnected *for sure*. The variable was already beeing unset before reuse, yet that was not enough. This doesn't like a big deal, I'm sure it can be done. Even without exception mode, a disconnected PDO object can happen (internet drops, MySQL dies, etc.), so that is not an argument against implementing a disconnect method. ------------------------------------------------------------------------ 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 https://bugs.php.net/bug.php?id=62065 -- Edit this bug report at https://bugs.php.net/bug.php?id=62065&edit=1

« previous php.bugs (#191317) next »