Transaction remains open after PDO query timeout in Phalcon 5.x
0 reputation · 01 May 2023, 16:20 UTC
0 reputation · 01 May 2023, 16:20 UTC
In Phalcon 5.x, setting PDO::ATTR_TIMEOUT on a database adapter enforces a statement execution timeout, but the framework does not specify whether an ensuing timeout exception should automatically roll back an active transaction.
The PDO driver throws an exception when the query exceeds the timeout, yet the transaction context remains open unless the application explicitly rolls back. This behavior differs from some ORMs that treat statement timeouts as fatal transaction errors.
Since the documentation and source code are silent on this point, projects implement inconsistent fallback logic — some catch the exception and roll back, others leave the transaction pending.
Should Phalcon's database abstraction layer automatically roll back the transaction when a PDO::ATTR_TIMEOUT exception occurs? Is there a recommended pattern for handling transaction state after a statement timeout in Phalcon 5.x applications? Does the behavior vary across supported PDO drivers (MySQL, PostgreSQL, SQLite) in ways that affect portability?
35775 reputation · 01 May 2023, 22:20 UTC
No. Phalcon 5.x does not automatically roll back a transaction when a PDO statement exceeds PDO::ATTR_TIMEOUT. The driver throws an exception, but the transaction context remains open until your application explicitly rolls it back or the connection ends.
This behavior applies to Phalcon 5.x database adapters built on PDO. The framework does not treat statement timeouts as fatal transaction errors. Version assumption: Phalcon 5.x stable releases. Do not assume this applies to other major versions without testing.
try/catch.PDOException after the timeout.$connection->rollback() in the catch block.$connection->begin();
try {
$connection->execute('UPDATE ...');
$connection->commit();
} catch (PDOException $e) {
$connection->rollback();
throw $e;
}
MySQL and PostgreSQL generally leave the transaction open after a statement timeout. SQLite may roll back on some fatal errors, but this is not guaranteed across versions. For portable Phalcon code, assume the transaction is open after any PDO exception and roll back explicitly for every driver.
Run a deliberately long query with PDO::ATTR_TIMEOUT set to a few seconds, catch the exception, then attempt another statement on the same connection. If it executes without error, the transaction is likely still open.
Which PDO driver are you using? SQLite-specific rollback behavior may need separate verification.
Use comments to ask for clarification. Post a solution as an answer.
7,090 reputation · 02 May 2023, 03:07 UTC
Assuming Phalcon 5.x with a PDO adapter, a PDO::ATTR_TIMEOUT exception does not automatically roll back an active transaction. The transaction context stays open until the application explicitly calls rollback(), which can retain locks on the connection.
Driver behavior differs: PostgreSQL typically aborts the current transaction on a statement timeout, requiring rollback before any further statement; MySQL InnoDB often leaves the transaction open for statement-level errors; SQLite treats the timeout as a busy-lock condition. Because ATTR_TIMEOUT support is driver-specific, verify the installed PDO driver before relying on it.
A practical check is to begin a transaction, execute a statement that exceeds the timeout, catch the exception, then run SELECT 1 to see whether the connection still accepts statements. Wrap the work in try/commit and catch/rollback, rethrowing after cleanup.