Edit report at https://bugs.php.net/bug.php?id=62065&edit=1
ID: 62065
Comment by: willfitch@php.net
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:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2012-05-18 20:26:16] b12 at bsdpower dot com
Description:
------------
Currently the advertised way of having pdo disconnect from the database is to assign
"null" to the pdo handle.
This may work acceptably well in tutorials, however in real life this approach is impractical.
When testing with, say, phpunit (dbunit), the setup code creates a connection and gives a pdo
instance to phpunit. What phpunit subsequently does with that instance and in particular how many
times the pdo variable is copied and assigned to cyclical and/or permanently referenced structures,
is not something that connection management code can control.
Example code from phpbb: https://github.com/phpbb/phpbb3/blob/develop/tests/test_framework/phpbb_database_test_connection_manager.php#L38
- connect function is called by phpunit.
Currently in phpbb tests the database connections are not closed by pdo. This requires for example
postgresql and oracle databases to be configured to allow more concurrent database connections than
we have tests in the test suite.
You might be tempted to say that it's phpunit's fault for not closing database
connections, or there is a bug in phpbb test code which results in connections not being closed.
Consider how such a bug might be found. If I close a connection when I think it should no longer be
used, and subsequently it is used, I will receive an error pointing to the responsible party. How
would you diagnose the same bug if there is no way to close a database connection explicitly?
Not to mention that disconnecting from the database is a core operation of any sane db api.
There is no need to change existing behavior of connection closing on finalization. The disconnect
method should be in addition to existing functionality.
Expected result:
----------------
PDO should provide a method on connections to disconnect from the database.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=62065&edit=1