Serializable schedules

To process transactions concurrently, the database server must execute some component statements of one transaction, then
some from other transactions, before continuing to process further operations from the first. The order in which the component
operations of the various transactions are interleaved is called the schedule.

Applying transactions concurrently in this manner can result in many possible outcomes, including the three particular inconsistencies
described in the previous section. Sometimes, the final state of the database also could have been achieved had the transactions
been executed sequentially, meaning that one transaction was always completed in its entirety before the next was started.
A schedule is called serializable whenever executing the transactions sequentially, in some order, could have left the database in the same state as the actual
schedule.

Serializability is the commonly accepted criterion for correctness. A serializable schedule is accepted as correct because
the database is not influenced by the concurrent execution of the transactions.

The isolation level affects a transaction's serializability. At isolation level 3, all schedules are serializable. The default
setting is 0.

Even when transactions are executed sequentially, the final state of the database can depend upon the order in which these
transactions are executed. For example, if one transaction sets a particular cell to the value 5 and another sets it to the
number 6, then the final value of the cell is determined by which transaction executes last.

Knowing a schedule is serializable does not settle which order transactions would best be executed, but rather states that
concurrency has added no effect. Outcomes which may be achieved by executing the set of transactions sequentially in some
order are all assumed correct.

The inconsistencies are typical of the types of problems that appear when the schedule is not serializable. In each case,
the inconsistency appeared because of the way the statements were interleaved; the result produced would not be possible if
all transactions were executed sequentially. For example, a dirty read can only occur if one transaction can select rows while
another transaction is in the middle of inserting or updating data in the same row.