Serializability
Serializability is the classical concurrency scheme. It ensures that a schedule for executing concurrent transactions is equivalent to one that executes the transactions serially in some order. It assumes that all accesses to the database are done using read and write operations. A schedule is called “correct” if we can find a serial schedule that is “equivalent” to it. Given a set of transactions T1…Tn, two schedules S1 and S2 of these transactions are equivalent if the following conditions are satisfied:
Read-Write Synchronization: If a transaction reads a value written by another transaction in one schedule, then it also does so in the other schedule.
Write-Write Synchronization: If a transaction overwrites the value of another transaction in one schedule, it also does so in the other schedule.
These two properties ensure that there can be no difference in the effects of the two schedules.
Database transaction
For this discussion a database transaction is a specific intended run (with specific parameters, e.g., with transaction identification, at least) of a computer program (or programs) that accesses a database (or databases). Such a program is written with the assumption that it is running in isolation from other executing programs, i.e., when running, its accessed data (after the access) are not changed by other running programs. Without this assumption the transaction’s results are unpredictable and can be wrong. The same transaction can be executed in different situations, e.g., in different times and locations, in parallel with different programs. A live transaction (i.e., exists in a computing environment with already allocated computing resources; to distinguish from a transaction request, waiting to get execution resources) can be in one of three states, or phases:
- Running – Its program(s) is (are) executing.
- Ready – Its program’s execution has ended, and it is waiting to be Ended (Completed).
- Ended (or Completed) – It is either Committed or Aborted (Rolled-back), depending whether the execution is considered a success or not, respectively . When committed, all its recoverable (i.e., with states that can be controlled for this purpose), durable resources (typically database data) are put in their final states, states after running. When aborted, all its recoverable resources are put back in their initial states, as before running.
A failure in transaction’s computing environment before ending typically results in its abort. However, a transaction may be aborted also for other reasons as well (e.g., see below).
Upon being ended (completed), transaction’s allocated computing resources are released and the transaction disappears from the computing environment. However, the effects of a committed transaction remain in the database, while the effects of an aborted (rolled-back) transaction disappear from the database. The concept of atomic transaction (“all or nothing” semantics) was designed to exactly achieve this behavior, in order to control correctness in complex faulty systems.
