Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128758
Precedence: list
MIME-Version: 1.0
References: <CANdUeaZhn-8b2+LZDV3UnT1sx+BVFcz=m7neQHyv7huGega+_Q@mail.gmail.com>
 <CE73D727-9546-469F-A723-FE667CA4061D@gmail.com> <CANdUeaZ0u-BmdUuX9XD--H2CA0zys+J8j5Cem4YQd2Q555m9Vw@mail.gmail.com>
 <CAGBsUrftu_-XfQQhKpBM_YJp_VOJJ1FyWNi+1wqZ+77q4LQSiQ@mail.gmail.com> <7b1f853f-1bb0-4d84-975b-164a71e092cc@allenjb.me.uk>
In-Reply-To: <7b1f853f-1bb0-4d84-975b-164a71e092cc@allenjb.me.uk>
Date: Wed, 1 Oct 2025 16:50:24 +0100
Message-ID: <CAGBsUrc3-M-wZYaF0nxFgcvrGkeeMHU3geRBw+FyOwn+q1z60Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [Discuss] Add PDO disconnect() and isConnected()
To: AllenJB <php.lists@allenjb.me.uk>
Cc: Robert Wolf <rposky@gmail.com>, Claude Pache <claude.pache@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: tekiela246@gmail.com (Kamil Tekiela)

On Wed, 1 Oct 2025 at 15:45, AllenJB <php.lists@allenjb.me.uk> wrote:
> As I understand it, at least in the case of MySQL, the state of
> persistent connections is not managed by MySQL, but by the client (PHP).
> This means that it's (at least theoretically) possible for a connection
> to end up in an undesirable state, in which case there should be a way
> to close it so it's not reused.

You are correct, and I can see this as a justification for adding a
dangerous function; however, the circumstances you describe are very
vague. What is this undesirable state, and how would someone be able
to determine in code that the connection is in an undesirable state?
More importantly, why would they need to close the connection when it
happens instead of restoring it to a working state? The most common
way I can imagine is if you acquire a lock on a table and then PHP
script gets aborted due to an unhandled exception from something else
(e.g. HTTP network request which failed due to outside reasons). But
in that case, the persistent connection should be cleaned up by the
custom error handler on the script's termination. Currently, there is
no way to do that other than manually trying to release all
locks/transactions/tables. A disconnect method would solve that, but
so would a method to trigger COM_CHANGE_USER, which is still a worse
solution than a simple function to reset the connection.

If borked persistent connections are a real problem that needs
solving, then I support adding a function to PDO to reset persistent
connections. In MySQL, it would trigger COM_RESET_CONNECTION, and in
other drivers an analogous solution would need to be found. This
avoids the problem of having the PDO instance in a borked state.

What I am trying to say is that there should be no need to ever close
a persistent connection. If it ever gets messed up, it should be
restored to the working state rather than being closed.