php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #63343 Commit failure for repeated persistent connection
Submitted: 2012-10-24 00:06 UTC Modified: 2021-06-14 09:03 UTC
Votes:5
Avg. Score:3.2 ± 1.3
Reproduced:1 of 3 (33.3%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: brn at macrovita dot com dot br Assigned:
Status: Analyzed Package: PDO related
PHP Version: Irrelevant OS: Mixed
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: brn at macrovita dot com dot br
New email:
PHP Version: OS:

 

 [2012-10-24 00:06 UTC] brn at macrovita dot com dot br
Description:
------------
Repeated transaction on repeated persistent PDO connection fails on commit with 
'There is no active transaction'.

Reproduced on:
- Fedora 14 32bit PHP 5.3.6 
- Gentoo 64bit PHP 5.3.14

We'll work around the bug in application code, but we thought developers might 
like to know about this.

// BTM5282

Test script:
---------------
# Should work, but does not:
cat <<'EOD' | php -d display_errors=1 && echo OK
<?php
$db = new PDO('sqlite::memory:', '', '', array(PDO::ATTR_PERSISTENT => true));
$db->beginTransaction();
$st = $db->query('select 1');
echo $st->fetchColumn()."\n";
$db->commit();
//$st = null;
$db = new PDO('sqlite::memory:', '', '', array(PDO::ATTR_PERSISTENT => true));
$db->beginTransaction();
$st = $db->query('select 2');
echo $st->fetchColumn()."\n";
$db->commit();
EOD
# INTERESTING? -> Works OK with uncommented $st = null;
# Works OK with PDO::ATTR_PERSISTENT => false .

Expected result:
----------------
1
2
OK

Actual result:
--------------
Fatal error: Uncaught exception 'PDOException' 
with message 'There is no active transaction' in -:11 ...

Patches

Add a Patch

Pull Requests

Pull requests:

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-12 04:07 UTC] ssufficool@php.net
-Summary: Commit failure for repeated transactions on repeated PDO persistent connections +Summary: SQLITE: Commit failure for repeated transactions on repeated PDO persistent conn
 [2014-01-01 12:28 UTC] felipe@php.net
-Package: PDO related +Package: PDO Core
 [2014-12-17 19:51 UTC] 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.
 [2016-08-31 23:30 UTC] cmb@php.net
-Summary: SQLITE: Commit failure for repeated transactions on repeated PDO persistent conn +Summary: Commit failure for repeated transactions on repeated PDO persistent conn -Status: Open +Status: Verified
 [2016-08-31 23:30 UTC] cmb@php.net
Confirmed: <https://3v4l.org/iTsHt>.
 [2016-09-01 21:46 UTC] cmb@php.net
-Summary: Commit failure for repeated transactions on repeated PDO persistent conn +Summary: Commit failure for repeated persistent connection
 [2016-09-01 22:32 UTC] cmb@php.net
-Status: Verified +Status: Analyzed
 [2016-09-01 22:32 UTC] 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.
 [2017-10-24 08:29 UTC] kalle@php.net
-Package: PDO Core +Package: PDO related
 [2021-06-10 10:42 UTC] 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>
 [2021-06-10 12:12 UTC] 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 13:32 UTC] cmb@php.net
> 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.
 [2021-06-14 09:03 UTC] nikic@php.net
> Still, I think users are better off to use a single PDO instance
> per persistent connection, in which case this issue would not
> happen.

Yes, I agree. If people want to share a connection, they should use the same object.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Fri Sep 17 02:03:36 2021 UTC