Phalcon PDO::ATTR_TIMEOUT transaction rollback behavior

Transaction remains open after PDO query timeout in Phalcon 5.x

0 reputation · 01 May 2023, 16:20 UTC

128K views0

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?

Keep exploring this topic

SQLSTATE[HY000] [2002] Connection refused when using persistent PDO connections in Phalcon

Diagnosing intermittent connection exhaustion in Phalcon’s persistent PDO connections: the framework surfaces a SQLSTATE[HY000] [2002] Connection refused error but offers no pool‑size limit or status metrics. What configuration options or monitoring hooks exist to mitigate this behavior?

Does Liquibase Support a Configurable Timeout for Whole Changeset Execution?

The goal is to allow a Liquibase update operation to be halted after a user‑defined duration, ensuring that any partially applied changeset can be rolled back or left in a known state.

Inconsistent Data Post-Commit in Mithril Cache

Investigating the precise timing of asynchronous cache updates in Mithril after a successful database commit, given that cache invalidation relies on transaction boundaries but the exact propagation latency is uncertain.

DataLoader timeout limits: worker processes persist after RuntimeError

When a PyTorch DataLoader timeout fires, the main process raises RuntimeError but the worker process keeps running. The loader enters an undefined state with no documented way to cancel the stuck worker or reset cleanly.

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.

Transaction remains open after PDO query timeout in Phalcon 5.x

0 answers

Your perspective belongs here.

1 question comment