Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128437 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 82AA31A00BC for ; Fri, 8 Aug 2025 14:46:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1754664276; bh=QCDblEFGp0mficnX2xMwnGU4u/dny88yKp4BCIAl5FM=; h=From:Date:Subject:To:From; b=Tv9xFr+YAryDprw9Qi0/HkECz5QPOGje35IwL0xxUls2ah1h0FogvPNemcoVMeCa+ vzZTWF+TiOgJRk6Hq2B1pZ3PEtYarodMSCrmFTgjGjlLOJGtckKfINfAFBDkeH82Ys qJILaezeUTtM/ujKtj/LxKTTSr3HCEJ9fumyAVjzAAm7hkR0cqSA5xYNgSaCrN6GUs G8/FFvceaLiWO08e/P/dtF9VmuUZAyvWq2B5+q1liA6gRJ4DZzIoi3wwnO1fEucMtm mRz0ym8Yj35+9JNnu317+6Tw+pffB7gB9hFBZbZYGK7/KsMgEyG3806i2FT4IBW0Gj xyxqZzjBMbZdg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1B31B18005D for ; Fri, 8 Aug 2025 14:44:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 8 Aug 2025 14:44:34 +0000 (UTC) Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-af95ecfbd5bso394786066b.1 for ; Fri, 08 Aug 2025 07:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754664372; x=1755269172; darn=lists.php.net; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=jqo8mWnkqw2zOdpKhsy29efoxgU6SeuRoGTMYQv15YM=; b=Ti0CxSsk6if1+LaWCriynQCF7k5jAe/RG2rfDuEQ6aG7hJz/9JCTApYugLaasOPt43 FD39vYX0as36yGL+/C43eQP7wD9Cxl8uPU42b2vgaQpy+zIbFr+SobXv/FZeww9hdtED E3+J/IaL6ZCv0YsxNrcIHLDAJ3LYICCEYDIKy2PCuWVWC1aQSngK92FIKwpcj7rAFml2 27TRM7TQoZmJ6YLxjFs9sPbOdvB7xcNvRgHn/7HfRQ+1BLv6D4rKiI4AP2b/8UGAupov pU2HRI0kqjw+zs4sDGmlDk56QgznRHQpo1NPhda9uZo58/fgmDSvlIgniPW2CStcjg2V U2CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754664372; x=1755269172; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jqo8mWnkqw2zOdpKhsy29efoxgU6SeuRoGTMYQv15YM=; b=Mpy88YP4V16U8mc3pQcz6OWSM4I/Z5s/t9npc3nsmhuwo2VttLVII6+LxxIGhQm/ND aGRuJjnuqJF8icliCmlNdWc2LFKt/b9hSewjhHCXCxc5Tp5dGWMvNYfqtmvr0CI+kDN5 xcowLxW5ci485yWBdTwyHd8xwXWHLsc1nJvYj4AmWjVPQPeW4Mg5o2jjHxSAivGL2fK0 zW3kigcb7KpvQqNFqz7jBDyff9N9p28dX+FuMJ1TXb7Z8LPiKwfcy/bcLUJ0UTK5sckv ZkBHrISa4MYRuOC/sojCiPL4bRvDZ1soILgBWq50r8p1HBF2x2p94Sk6yXOt7R76rDa3 bBKg== X-Gm-Message-State: AOJu0YxmEvVO5MRtcmgjmR4fV4Vu2GVTvp8mDRZKrp1nPS47lsIPOIqu kDsYoy2GiqIdJFq5B5LxOiBxiOcPrMNGgwU15K9VZ9XCFhwti0QAp0IPJB0sKYzU6uU8BtrN5zR wGYJoFG1XCLOsjpOA3yKTXUyBT6DPXHiQtS9m X-Gm-Gg: ASbGncsfKMnMHvlBpJ5AdyCJ5Fxgi0WzChyz9xv4/3QGHTvJ30rtMiov20O/KlJxF1m SVjrDTVwrwx9TXf/tHRxpahHSwVBTcy0uqxUS5ma76Q5kCt+WHEDKMEP/Tr4CdQKuEx/PRwNLWe tHjQn9lgOIpQCdyg343ammT6wWf8r0D2RYcAehthcSnPf2kUEMYp/6MRj067/8eQpeLGPdsFg06 WvMGw== X-Google-Smtp-Source: AGHT+IHvNAmLZVkgfIotFywpv9aUWZvmSVLssiRF3SpMwoW1rSZt+BfkT0IAyvVhC48H9gl/pDzUwdNs9Wr2EcfUZZI= X-Received: by 2002:a17:906:c14c:b0:af9:2bb9:ea36 with SMTP id a640c23a62f3a-af9c640cff7mr311407766b.7.1754664371931; Fri, 08 Aug 2025 07:46:11 -0700 (PDT) Precedence: list list-help: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 Date: Fri, 8 Aug 2025 10:46:00 -0400 X-Gm-Features: Ac12FXy9guEYSv3MevhxM42AF8y1bnZeUMfgWqSfAlysmCFDaXhkafIyDaUeEE0 Message-ID: Subject: [PHP-DEV] PDO Disconnect and Persistent Connect To: internals@lists.php.net Content-Type: multipart/alternative; boundary="00000000000096d1a0063bdba2d0" From: rposky@gmail.com (Robert Wolf) --00000000000096d1a0063bdba2d0 Content-Type: text/plain; charset="UTF-8" Hello PHP, I am writing per the RFC guidelines and requesting initial feedback, as I am considering an RFC to add a PDO::disconnect method as well as to improve handling (or removal?) of persistent connections during PDO object creation and deletion. Should the RFC go forward, I would propose to implement any changes. I have submitted a preliminary pull request where some discussion has occurred, and an implementation proof-of-concept relayed. - https://github.com/php/php-src/pull/19214 The following is the rationale provided in the pull request for a disconnect method. Current recommendations in PDO application integration avoid the need for an explicit disconnect routine and workaround the [below] described issues through prescribed use of a single PDO object instance for any given database connection, and which database connection is terminated upon either PDO object destruct or, in the case of persistent connections, at the end of script execution. While the use of a singleton object for database connection handling within applications is a common implementation pattern, the tight integration of database disconnect behavior with PHP's object free hook has imposed a need to further manage PDO object references within an application in order to reliably replace and/or shutdown a db connection instance, an effort which scales with application complexity. This reality is further complicated by the PDO statement object, which also holds a reference to a PDO object and thus must also be managed from a reference standpoint, as well as by PHP itself, which governs the time at which an object free hook is invoked, subject to influence by bug or design. That latter point about PHP's imperfect invocation of the object free hook may raise eyebrows, but it is actually the precursor to this project for me. I recently tripped over a confluence of factors involving persistent PDO connections, exceptions, and xdebug, in which a PDO object's free hook is not being invoked upon removal of all object references and instead occurs at an inopportune time during use of a subsequent PDO object, also prompting an undesirable transaction rollback on the shared inner database connection. I can provide more detail here, and/or an example to reproduce, but I'm not sure it's desirable, given the involvement of xdebug and the development mode that implies. Rather, it is a case in point to promote a preference for an explicit interface governing PDO end-of-life behavior, putting more control in users' hands. A disconnect method has been suggested before, and several times at that (see below references), but I have not found an RFC for it. - https://marc.info/?l=php-internals&m=145338688709155 - [contd.] https://marc.info/?l=php-internals&m=145346982831131 - https://bugs.php.net/bug.php?id=62065 - https://bugs.php.net/bug.php?id=67473 - https://bugs.php.net/bug.php?id=40681 As for persistent PDO connections, I understand the feature is much disliked, which I suspect is owing to the memory constraints it places on PDO extensions that have not been perfectly abided by. In the above pull request, I am smoothing over a couple rough edges (see: https://bugs.php.net/bug.php?id=63343), but testing reveals there are more. Perhaps the better service I can be here is to propose the removal of this feature altogether? The added complexity of the feature seems to outweigh the benefits, which as best I can gather, is primarily to allow for ad-hoc PDO object creation. If that is truly all it brings in benefit, this is a use case easily supported by the user via singleton. From what I have seen of PDO implementation, persistent connection behavior is based upon the "PERSISTENT" constructor attribute and the internal sense variable "is_persistent", such that this feature is rather auxiliary and may be easily culled. The "is_persistent" PDO struct member could remain for the foreseeable future, to allow PDO extensions more grace in their own removal of feature support. It may be that these ideas would warrant two RFCs, but I'll leave it at that for now and await further feedback. Thank you, Robert Wolf --00000000000096d1a0063bdba2d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello PHP,

I am writing per the RFC guidelines and = requesting initial feedback, as I am considering an RFC to add a PDO::disco= nnect method as well as to improve handling (or removal?) of persistent con= nections during PDO object creation and deletion.

Should the RFC go = forward, I would propose to implement any changes. I have submitted a preli= minary pull request where some discussion has occurred, and an implementati= on proof-of-concept relayed.
=C2=A0 -=C2=A0https://github.com/php/php-src/pull/19214

The= following is the rationale provided in the pull request for a disconnect m= ethod.

Current recommendations in PDO application integration avoid = the need for an explicit disconnect routine and workaround the [below] desc= ribed issues through prescribed use of a single PDO object instance for any= given database connection, and which database connection is terminated upo= n either PDO object destruct or, in the case of persistent connections, at = the end of script execution. While the use of a singleton object for databa= se connection handling within applications is a common implementation patte= rn, the tight integration of database disconnect behavior with PHP's ob= ject free hook has imposed a need to further manage PDO object references w= ithin an application in order to reliably replace and/or shutdown a db conn= ection instance, an effort which scales with application complexity. This r= eality is further complicated by the PDO statement object, which also holds= a reference to a PDO object and thus must also be managed from a reference= standpoint, as well as by PHP itself, which governs the time at which an o= bject free hook is invoked, subject to influence by bug or design.

T= hat latter point about PHP's imperfect invocation of the object free ho= ok may raise eyebrows, but it is actually the precursor to this project for= me. I recently tripped over a confluence of factors involving persistent P= DO connections, exceptions, and xdebug, in which a PDO object's free ho= ok is not being invoked upon removal of all object references and instead o= ccurs at an inopportune time during use of a subsequent PDO object, also pr= ompting an undesirable transaction rollback on the shared inner database co= nnection. I can provide more detail here, and/or an example to reproduce, b= ut I'm not sure it's desirable, given the involvement of xdebug and= the development mode that implies. Rather, it is a case in point to promot= e a preference for an explicit interface governing PDO end-of-life behavior= , putting more control in users' hands.

A disconnect method has = been suggested before, and several times at that (see below references), bu= t I have not found an RFC for it.
=C2=A0 -=C2=A0https://marc.info/?l=3Dphp-inter= nals&m=3D145338688709155
=C2=A0 - [contd.]=C2=A0https://marc.info/?l=3Dp= hp-internals&m=3D145346982831131
=C2=A0 -=C2=A0https://bugs.php.net/bug.php?id=3D62065=C2=A0 -=C2=A0https://bugs= .php.net/bug.php?id=3D67473
=C2=A0 -=C2=A0https://bugs.php.net/bug.php?id=3D40681

As f= or persistent PDO connections, I understand the feature is much disliked, w= hich I suspect is owing to the memory constraints it places on PDO extensio= ns that have not been perfectly abided by. In the above pull request, I am = smoothing over a couple rough edges (see:=C2=A0https://bugs.php.net/bug.php?id=3D63343), but testing= reveals there are more. Perhaps the better service I can be here is to pro= pose the removal of this feature altogether? The added complexity of the fe= ature seems to outweigh the benefits, which as best I can gather, is primar= ily to allow for ad-hoc PDO object creation. If that is truly all it brings= in benefit, this is a use case easily supported by the user via singleton.=

From what I have seen of PDO implementation, persistent connection = behavior is based upon the "PERSISTENT" constructor attribute and= the internal sense variable "is_persistent", such that this feat= ure is rather auxiliary and may be easily culled. The "is_persistent&q= uot; PDO struct member could remain for the foreseeable future, to allow PD= O extensions more grace in their own removal of feature support.

It = may be that these=C2=A0ideas would warrant two RFCs, but I'll leave it = at that for now and await further feedback.

Thank you,
Robert Wol= f
--00000000000096d1a0063bdba2d0--