Bug #63343 [Ana]: Commit failure for repeated persistent connection

From: Date: Thu, 10 Jun 2021 13:32:59 +0000
Subject: Bug #63343 [Ana]: Commit failure for repeated persistent connection
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-234348@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=63343&edit=1

 ID:                 63343
 Updated by:         cmb@php.net
 Reported by:        brn at macrovita dot com dot br
 Summary:            Commit failure for repeated persistent connection
 Status:             Analyzed
 Type:               Bug
 Package:            PDO related
 Operating System:   Mixed
 PHP Version:        Irrelevant
 Block user comment: N
 Private report:     N

 New Comment:

> IIRC the connection pooling is per process/thread, and there can
> only be one request per process/thread at a time.

Oh, you're right! (otherwise there would be more serious issues)

Still, I think users are better off to use a single PDO instance
per persistent connection, in which case this issue would not
happen.


Previous Comments:
------------------------------------------------------------------------
[2021-06-10 12:12:51] nikic@php.net

> (from the same request, but even worse also from other requests)

Is that really the case? IIRC the connection pooling is per process/thread, and there can only be
one request per process/thread at a time.

------------------------------------------------------------------------
[2021-06-10 10:42:00] cmb@php.net

Actually, Nikita's analysis[1] is spot on:

| The problem as I see it is that destruction of one of the PDO
| objects will always rollback the transaction on the inner object
| (if a transaction is active). In this case this backfires because
| in the meantime another transaction has been opened through a
| different PDO object (but same inner object).

It seems to me that this very issue is only an edge case of the
more general issue that connections that are in use also can be
reused (from the same request, but even worse also from other
requests).  I.e. any global state (change) of the connection
(inner object) can affect other code in unforeseen ways.

[1] <https://github.com/php/php-src/pull/2112#discussion_r77312340>

------------------------------------------------------------------------
[2016-09-01 22:32:38] cmb@php.net

This is a memory management issue, as setting $st = null hints
at. Furthermore, assigning the second $db->query() to something
else than $st (e.g. $st1) also lets the script succeed.

The fix for PHP-7.0+ appears to be trivial (see PR #2112), but I
don't know how to solve the problem for PHP-5.6.

------------------------------------------------------------------------
[2016-08-31 23:30:55] cmb@php.net

Confirmed: <https://3v4l.org/iTsHt>.

------------------------------------------------------------------------
[2014-12-17 19:51:42] brn at macrovita dot com dot br

Note: This bug is NOT specific to SQLite.

The original test case uses SQLite just because it makes it simpler to reproduce the problem.

Originally, we ran into this bug with connections against MySQL.

------------------------------------------------------------------------


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=63343


--
Edit this bug report at https://bugs.php.net/bug.php?id=63343&edit=1


Thread (9 messages)

« previous php.bugs (#234348) next »