Transaction Processing
What is a transaction?
A transaction on a database is a series of queries and changes that externally appear to be atomic. To the outside observer, the transaction either happens entirely or not at all.
Internal and external transactions
Internal transactions: values are read, perhaps more values conditionally read, and then values are changed based on the values read. All values read or written are inside the database. The DBMS can guarantee atomicity because it controls all the state involved.
External “transactions”: the idea of an external transaction does not really exist. Some changed values or side effects (like sending an SMS acknowledgement) are external to the DBMS. The DBMS cannot help make these atomic; system designers must think carefully about undoing them. If a transaction that sent an SMS is later aborted, the SMS has already been delivered and cannot be recalled.
Many DBMS systems allow the application to abort a transaction before it is committed. This is a topic covered in Part IB Concurrent Systems.
Transaction client flow
The lifecycle of a transaction from the client’s perspective:
th = transaction_start()
-- any number of queries and updates, in any order
-- ...
rc = transaction_commit(th)
-- or: transaction_abort(th)If aborted, all updates made within the transaction are undone by the DBMS. The application programmer does not need to write undo logic for database state.
In some (optimistic) systems, transaction_commit may itself abort. When this happens, the client must restart the transaction from the beginning.
Concurrency
DBMSs support concurrent transactions. Multiple clients can have active transactions simultaneously. The ‘start’ and ‘commit’ calls bracket the body of each transaction. The DBMS is responsible for ensuring that concurrent transactions do not interfere with one another in ways that violate the ACID properties.
Key points
| Aspect | Description |
|---|---|
| Internal vs. external | DBMS can only guarantee atomicity for data it controls |
| Client API | start, queries/updates, commit or abort |
| Abort semantics | All database changes are rolled back automatically |
| Optimistic systems | Commit itself may fail; client must retry |
| Concurrency | Multiple transactions overlap in time; DBMS arbitrates |
Summary
- A transaction is an atomic sequence of database operations.
- The DBMS can guarantee atomicity for internal state, but not for external side effects.
- The client API follows a start-query-commit/abort pattern.
- Concurrent transactions are supported; the DBMS manages isolation.