Transactions

database is partitioned into items (e.g., tuple, attribute)
transaction
- any one execution of a program in a DBMS
- **sequence of one or more operations on a database: read / write / commit / abort (**final operation: commit or abort)
I – an item in a DB (any one execution of a program in a DBMS)
fundamental operations in a transaction T (T can be omitted when clear from context):
- read(T, I)
- write(T, I)
- commit(T)
  - successful completion: T’s changes are to become permanent
- abort(T)
  - T is rollbacked: its changes are undone

Properties – ACID

properties a DBMS must ensure for a transaction in order to maintain data in the presence of concurrent execution/system failures

a transaction is atomic
either all the operations in the transaction are executed, or none are (all-or-nothing)
a transaction can:
- commit
  - after finalizing all its operations (successful completion)
- abort
  - after executing some of its operations
  - the DBMS can itself abort a transaction (the DBMS logs all transactions' writes, so it can undo them if necessary (i.e. undo the actions of incomplete transactions))
user’s perspective:
- either all operations in a transaction are executed, or none are
- the transaction is treated as an indivisible unit of execution
crash recovery guarantees atomicity in the presence of system crashes

e.g.

Consider the following transaction transferring money from AccountA to AccountB: AccountA ← AccountA - 100 AccountB ← AccountB + 100

If the transaction fails in the middle, 100 lei must be restored to AccountA, i.e. partial effects are undone

a transaction must preserve the consistency of the database after execution, i.e. a transaction is a correct program
in the absence of other transactions, a transaction that executes on a consistent database state leaves the database in a consistent state