Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128746
Precedence: list
MIME-Version: 1.0
References: <CANdUeaZhn-8b2+LZDV3UnT1sx+BVFcz=m7neQHyv7huGega+_Q@mail.gmail.com>
 <CAGBsUrd_-6UmqedKs1x95Uj2bb8GkBvYHJaFkvrnnoKTq_O=QA@mail.gmail.com>
 <CAPhkiZyYL72x93E-M2BNAN7vfN-7DSNmoXvS+KOSPgAoo7qjSg@mail.gmail.com> <CAGBsUrcPL4uPu_ehRJOC5qqu8OAK+=_a4KuhXiRhzkLMrTe_vQ@mail.gmail.com>
In-Reply-To: <CAGBsUrcPL4uPu_ehRJOC5qqu8OAK+=_a4KuhXiRhzkLMrTe_vQ@mail.gmail.com>
Date: Tue, 30 Sep 2025 11:35:15 -0400
Message-ID: <CANdUeabk8tZ0BZdNR6MNXiGNgVHh57nNXM=AWm5SWVEL6jOg1A@mail.gmail.com>
Subject: Re: [PHP-DEV] [Discuss] Add PDO disconnect() and isConnected()
To: Kamil Tekiela <tekiela246@gmail.com>
Cc: Andrey Andreev <narf@devilix.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000060c13806400680ba"
From: rposky@gmail.com (Robert Wolf)

--00000000000060c13806400680ba
Content-Type: text/plain; charset="UTF-8"

>
> I find this proposal to be a backwards step in the age when we are
> moving away from resources and their explicit closure. We have
> disabled this in PHP 8.0 for curl_close(), imagedestroy(),
> openssl_pkey_free(), shmop_close() and xml_parser_free().


Thank you for providing these recent examples of resource-to-object
conversions. As you well know, PDO is an object which also optionally uses
PHP persistent resources to facilitate connection re-use across PHP
requests, a feature which I don't believe has a parallel in object space.
Perhaps therein lies a feature request, i.e. to allow an object to be made
persistent in the same way a resource can.

However, as there is no present path for PDO's conversion away from PHP
persistent resources, the prior examples you highlight seem to support an
explicit close interface in PDO, in that so long as PHP resources are
involved, a close method is warranted.

PDO was designed much
> better and it deliberately avoided the foot gun that is explicit
> connection closure.


I'll push back on the notion that disconnect() is likely to be a foot gun.

In general, a held PDO object does not guarantee an active connection to a
database. Remote connection closures do occur. Networks falter and fail. A
robust application necessarily accounts for connectivity failure states,
and in the case of PDO, is likely validating the success of every database
interaction and reacting accordingly.

Considering, an implementation which unwittingly invokes disconnect() and
permits continued use of the same PDO for database interactions will at
least not error in novel ways. The recommendation for avoiding such
mistakes in implementation would be the same which the community has long
advocated for - decorate your PDOs.

Maybe there are legitimate use cases for this, but
> there are also alternatives.


I listed a couple use cases in the RFC, which I'll quote below for some
added context.

* Efficient management of database resources across periods of application
idleness, opening and closing connection as needed.
* Interoperability with database environment imposing timeout or other
session constraints, necessitating multiple connections during script
execution.
* Abnormal termination procedure in which database closure is highly
prioritized, e.g. security violation.
* Testing purposes, e.g. simulation of remote connection failure.

Pretty much every time I hear the
> argument that it would be nice if PDO had it, I can reply with: you
> can just design your code in a way that doesn't need it.


I tried responding to this in the RFC, also quoted below.

PHP makes the implementation of a decorator simple enough through magic
methods like __call and __get, but this is complicated in PDO by the PDO
statement object, which holds reference to a PDO object, and so must also
be reference-managed. A leak-proof decorator should thus override
PDO::prepare() and PDO::query() to also prevent the leak of the PDO
statement object, likely requiring additional interfaces to otherwise
interact with prepared PDO statements, to e.g. bind parameters and execute
them, and queried PDO statements, to e.g. fetch one row, N rows, one
column, etc. This prescribed implementation pattern is burdensome.

For persistent PDO objects, the user has no native capacity to close a
connection, given that the database handle is inaccessible and registered
as a PHP persistent resource, which remains until the PHP process
terminates. To ensure database connectivity across subsequent PHP requests,
each new PDO object includes a liveness check on the persistent connection,
possibly prompting a new connection. This has meant the burden of defining
a viable database connection resides within the database driver's liveness
check, and that an outcome differing with actual viability as it concerns a
given application results in a non-viable database connection for all
subsequent PHP requests. The proposed disconnect() thus grants the user the
capacity to declare a connection as no-longer viable.

--00000000000060c13806400680ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex">I find this proposal to be a backwards st=
ep in the age when we are<br>moving away from resources and their explicit =
closure. We have<br>disabled this in PHP 8.0 for curl_close(), imagedestroy=
(),<br>openssl_pkey_free(), shmop_close() and xml_parser_free().</blockquot=
e><div dir=3D"ltr"></div>
<div><br></div><div>Thank you for providing these recent examples of resour=
ce-to-object conversions. As you well know, PDO is an object which also opt=
ionally uses PHP persistent resources to facilitate connection re-use acros=
s PHP requests, a feature which I don&#39;t believe has a parallel in objec=
t space. Perhaps therein lies a feature request, i.e. to allow an object to=
 be made persistent in the same way a resource can.</div><div><br></div><di=
v>However, as there is no present path for PDO&#39;s conversion away from P=
HP persistent resources, the prior examples you highlight seem to support a=
n explicit close interface in PDO, in that so long as PHP resources are inv=
olved, a close method is warranted.<br></div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex=
">PDO was designed much<br>better and it deliberately avoided the foot gun =
that is explicit<br>connection closure.</blockquote><div><br></div>I&#39;ll=
 push back on the notion that disconnect() is likely to be a foot gun.<br><=
br>In general, a held PDO object does not guarantee an active connection to=
 a database. Remote connection closures do occur. Networks falter and fail.=
 A robust application necessarily accounts for connectivity failure states,=
 and in the case of PDO, is likely validating the success of every database=
 interaction and reacting accordingly.<br><br><div>Considering, an implemen=
tation which unwittingly invokes disconnect() and permits continued use of =
the same PDO for database interactions will at least not error in novel way=
s. The recommendation for avoiding such mistakes in implementation would be=
 the same which the community has long advocated for - decorate your PDOs.<=
/div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex">Maybe there are legitimate use cases f=
or this, but<br>there are also alternatives.=C2=A0</blockquote><div><br></d=
iv><div>I listed a couple use cases in the RFC, which I&#39;ll quote below =
for some added context.=C2=A0</div><div><br></div><div>* Efficient manageme=
nt of database resources across periods of application idleness, opening an=
d closing connection as needed.<br>* Interoperability with database environ=
ment imposing timeout or other session constraints, necessitating multiple =
connections during script execution.<br>* Abnormal termination procedure in=
 which database closure is highly prioritized, e.g. security violation.<br>=
* Testing purposes, e.g. simulation of remote connection failure.<br></div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex">Pretty much every time I hear the<br>argume=
nt that it would be nice if PDO had it, I can reply with: you<br>can just d=
esign your code in a way that doesn&#39;t need it.=C2=A0</blockquote><div><=
br></div>I tried responding to this in the RFC, also quoted below.<br><br>P=
HP makes the implementation of a decorator simple enough through magic meth=
ods like __call and __get, but this is complicated in PDO by the PDO statem=
ent object, which holds reference to a PDO object, and so must also be refe=
rence-managed. A leak-proof decorator should thus override PDO::prepare() a=
nd PDO::query() to also prevent the leak of the PDO statement object, likel=
y requiring additional interfaces to otherwise interact with prepared PDO s=
tatements, to e.g. bind parameters and execute them, and queried PDO statem=
ents, to e.g. fetch one row, N rows, one column, etc. This prescribed imple=
mentation pattern is burdensome.<br><br><div>For persistent PDO objects, th=
e user has no native capacity to close a connection, given that the databas=
e handle is inaccessible and registered as a PHP persistent resource, which=
 remains until the PHP process terminates. To ensure database connectivity =
across subsequent PHP requests, each new PDO object includes a liveness che=
ck on the persistent connection, possibly prompting a new connection. This =
has meant the burden of defining a viable database connection resides withi=
n the database driver&#39;s liveness check, and that an outcome differing w=
ith actual viability as it concerns a given application results in a non-vi=
able database connection for all subsequent PHP requests. The proposed disc=
onnect() thus grants the user the capacity to declare a connection as no-lo=
nger viable.=C2=A0</div></div>

--00000000000060c13806400680ba--