A transaction schedule is an ordering of several
transactions or - more often - of the
operations of several transactions. It is needed in
database theory to define serializability, an important concept
used to maintain two of the ACID principles of transactions:
isolation and consistency.
In most cases the operations of the transactions shown in the
schedule are only reads and writes, since in the
standard case only those are necessary to determine the
serializeability of a schedule (i.e. the existence of a reordering
of all operations so that in the end all transactions are executed
one after another and not interwoven). But some non-standard
approaches also take the actual calculations into
account to improve serializability. Have e.g. a look at the following
schedule, in which two transactions concurrently change the content
of datum x :
T1 T2
V1:=Read(x)
V1:=V1*2
Write(x,V1)
V3:=Read(x)
V3:=V3+1
Write(x,V3)
V2:=Read(x)
V2=V2+1
Write(x,V2)
If just the read and write operations are observed, there is a
conflict between T1 and T2 since T2
reads and writes intermediate results of T1 violating
isolation. But knowing the actual calculations, one can take
advantage of the commutativity of the addition. The serial
schedule T1-T2 (i.e. first complete execution
of T1 then of T2) is then equivalent and the
above schedule therefore serializeable.