Transaction failure during execution: What is the preferred recovery action when an in-progress transaction terminates abnormally (for example, due to an application error)?

Introduction / Context:
ACID properties guarantee that incomplete or erroneous transactions do not corrupt the database. When a transaction fails mid-flight, the database must restore the prior consistent state for the affected rows. Understanding proper recovery actions preserves integrity and avoids partial updates.

Given Data / Assumptions:

• The failure concerns a single running transaction (logic error, deadlock victim, explicit abort).
• The DBMS supports transactional logs and undo mechanisms.
• System-wide failure is not implied.

Concept / Approach:

Rollback undoes all changes made by the current transaction, restoring pre-transaction state. This satisfies atomicity: the unit of work either fully completes (commit) or has no effect (rollback). Rollforward, by contrast, replays committed changes from logs after a crash to bring the database ahead to a consistent point, which is not the use case here.

Step-by-Step Solution:

Verification / Alternative check:

Check the log: after rollback, no part of the failed transaction is visible to other sessions; isolation is maintained.

Why Other Options Are Wrong:

Rollforward applies after system crashes to redo committed work, not to undo a single failed transaction.

Switching to a duplicate database or reprocessing transactions is overkill for this scenario and used for broader recovery strategies.

Common Pitfalls:

Leaving long-running transactions open, which can escalate locks and increase rollback cost; not handling deadlock retries gracefully at the application tier.

Final Answer:

Rollback