What happens to in-flight transactions during a database outage depends on how far each transaction got, what failed, and the database’s durability settings. Work that had not committed is generally rolled back during recovery; durably committed work is generally recovered from the database log. But if a client connection breaks while COMMIT is underway, the client may not know whether the transaction succeeded. A server crash, a lost client connection, and a failure during distributed commit are different situations—and can have different outcomes.
Transaction state determines what happens
“In flight” can mean an operation is still running, the server has committed it but the reply is in transit, or a distributed transaction is waiting for a final decision. Those states matter more than the fact that an outage occurred.
| Transaction state when the failure occurs | Likely database outcome | What the client can know |
|---|---|---|
| Active work that has not committed | Typically rolled back as the database recovers. MySQL’s InnoDB documentation says it rolls back transactions that were neither committed nor in XA PREPARE state when the server exited; PostgreSQL uses write-ahead log (WAL) recovery to restore a consistent state. MySQL InnoDB recovery; PostgreSQL WAL. |
If the client receives a clear error before attempting commit, the work may be known to have failed. If the connection disappears during commit, treat the result as unknown until checked. |
| Committed work under normal synchronous durability | Expected to survive a server crash: recovery can replay log records even if updated data pages had not yet been written. PostgreSQL describes the synchronous-commit guarantee in its asynchronous commit documentation. | A received success response normally indicates commit, subject to the database’s commit mode and durability configuration. |
| Server committed, but the client did not receive the reply | The transaction may already have taken effect; the lost reply does not undo it. | The client has an unknown outcome. A timeout or disconnect alone does not prove that the transaction failed. Oracle’s COMMIT reference also describes a NOWAIT option that can acknowledge before redo records are written. |
| Prepared distributed transaction awaiting resolution | The transaction can remain in-doubt if two-phase commit is interrupted before its final decision. Oracle says automatic recovery usually resolves it after communication returns; locks may remain while the outcome is unresolved. Oracle distributed transactions; Oracle transactions. | One participant or application may not be able to establish the final outcome on its own while the other participants are unreachable. |
These are typical outcomes, not a universal rule for every engine or failure. PostgreSQL’s WAL documentation explains how logged changes support recovery, while MySQL’s documentation describes InnoDB’s own recovery behavior; consult the documentation for the database release and configuration actually in use.
Why the kind of outage matters
A database-process crash can leave the host and storage available for recovery. A host or storage failure can also interrupt access to the log or expose a durability problem, depending on the system and its configuration. A network failure may leave the database running and the transaction completed while the client is disconnected. In a distributed transaction, a participant or network failure can interrupt coordination itself.
#1 Best Overall
To reason about a particular incident, identify three things: what failed, the transaction’s state at that moment, and the commit and durability settings in effect. “The database was down” does not answer whether a request committed or whether only its response was lost.
Durability settings can change what a commit acknowledgment means
A successful commit acknowledgment is not independent of configuration. PostgreSQL documents that asynchronous commit can acknowledge before WAL is on disk, creating a brief window in which a crash can lose recently acknowledged transactions. Its documentation contrasts that behavior with synchronous commit, for which it states: “The client is therefore guaranteed that a transaction reported to be committed will be preserved, even in the event of a server crash immediately after.” That statement describes the normal synchronous behavior discussed in the PostgreSQL asynchronous commit documentation; it should not be applied to asynchronous commit.
Rank #2
Oracle’s SQL reference documents another specific exception: COMMIT WRITE NOWAIT can return before redo is persisted. Check the database release, transaction mode, and durability configuration before interpreting an acknowledgment as proof of crash durability. The PostgreSQL and Oracle options are examples, not interchangeable settings.
Recovery may restore service before all rollback work is finished
Recovery is not always a single moment when every transaction is fully settled. InnoDB can accept new connections after applying redo while it continues rolling back incomplete transactions in a background thread. MySQL notes that those rollbacks can temporarily cause locking conflicts for new connections. A service accepting connections therefore does not necessarily mean every recovery task is complete. See MySQL InnoDB recovery.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →What to do when a connection drops during COMMIT
- Do not assume the request failed. A disconnect while
COMMITis in progress leaves the client’s outcome uncertain unless the application received an unambiguous result. - Reconnect and check for a durable operation identifier. Use the transaction ID, request ID, or business-operation identifier that the application recorded, then confirm whether the intended effect exists. The exact status check depends on the database and application.
- Retry only after checking. If the operation’s status is still uncertain, blindly repeating it can apply the business action twice.
- Make retries safe where possible. Design operations to be idempotent—for example, use a unique idempotency key or business-operation identifier so a repeat can be recognized and handled rather than duplicated.
These steps address the gap between server completion and client receipt of a response. They are application-design guidance; no single status-check command or recovery procedure applies across all databases.
Quick Recap
Rank #4
- HP ProLiant DL360 G7 8B Server
- 2x X5650 2.66GHz 12-Cores Total
- 32GB RAM / 8x 146GB 10K 2.5in SAS Hard Drives
- P410 w/ 512MB
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
