Transaction Management

A transaction is a unit of program execution that

accesses and possibly updates various data items.
ACID Properties:
▪ Atomicity. Either all operations of the transaction
are properly reflected in the database or none are.
▪ Consistency. Execution of a transaction in isolation
preserves the consistency of the database.
▪ Isolation. Although multiple transactions may
execute concurrently, each transaction must be
unaware of other concurrently executing
transactions. Intermediate transaction results must
be hidden from other concurrently executed
transactions.
• That is, for every pair of transactions Ti and Tj, it
appears to Ti that either Tj, finished execution
before Ti started, or Tj started execution after Ti
finished.
▪ Durability. After a transaction completes
successfully, the changes it has made to the
database persist, even if there are system failures.
#Transaction State
▪ Active – the initial state; the transaction stays in this
state while it is executing
▪ Partially committed – after the final statement has
been executed.
▪ Failed -- after the discovery that normal execution
can no longer proceed.
▪ Aborted – after the transaction has been rolled back
and the database restored to its state prior to the
start of the transaction. Two options after it has
been aborted:
• Restart the transaction
▪ Can be done only if no internal logical error
• Kill the transaction
▪ Committed – after successful completion.
 ▪ Schedule – a sequences of instructions that specify
the chronological order in which instructions of
concurrent transactions are executed
• A schedule for a set of transactions must consist
of all instructions of those transactions
• Must preserve the order in which the
instructions appear in each individual
transaction.
▪ A transaction that successfully completes its
execution will have a commit instructions as the last
statement
• By default transaction assumed to execute
commit instruction as its last step
▪ A transaction that fails to successfully complete its
execution will have an abort instruction as the last
statement
#Serializability
A (possibly concurrent) schedule is serializable if it is
equivalent to a serial schedule.
1. Conflict serializability
2. View serializability.
 ▪ Instructions li and lj of transactions Ti and Tj
respectively, conflict if and only if there exists some
item Q accessed by both li and lj, and at least one of
these instructions wrote Q.
1. li = read(Q), lj = read(Q). li and lj don’t conflict.
2. li = read(Q), lj = write(Q). They conflict.
3. li = write(Q), lj = read(Q). They conflict
4. li = write(Q), lj = write(Q). They conflict
▪ If li and lj are consecutive in a schedule and they do
not conflict, their results would remain the same
even if they had been interchanged in the schedule.
#Conflict Serializability
If a schedule S can be transformed into a schedule S’ by a
series of swaps of non-conflicting instructions, we say
that S and S’ are conflict equivalent. We say that a
schedule S is conflict serializable if it is conflict equivalent
to a serial schedule.
Left_ schedule 3 Right_Schedule 6
Schedule 3 can be transformed into Schedule 6, a serial
schedule where T2 follows T1, by series of swaps of non-
conflicting instructions. Therefore Schedule 3 is conflict
serializable.

Example of a schedule that is not conflict serializable:

We are unable to swap instructions in the above

schedule to obtain either the serial schedule < T3, T4 >, or
the serial schedule < T4, T3 >.

#View Serializability
▪ Let S and S’ be two schedules with the same set of
transactions. S and S’ are view equivalent if the
following three conditions are met, for each data
item Q,.
1. If in schedule S, transaction Ti reads the initial value of
Q, then in schedule S’ also transaction Ti must read the
initial value of Q.
2. If in schedule S transaction Ti executes read(Q), and
that value was produced by transaction Tj (if any), then
in schedule S’ also transaction Ti must read the value of Q
that was produced by the same write(Q) operation of
transaction Tj .
3. The transaction (if any) that performs the final
write(Q) operation in schedule S must also perform the
final write(Q) operation in schedule S’.

A schedule S is view serializable if it is view equivalent to

a serial schedule. Every conflict serializable schedule is
also view serializable.

view but not conflict

Every view serializable schedule that is not conflict
serializable has blind writes.
Test for Conflict Serializability
▪ A schedule is conflict serializable if and only if its
precedence graph is acyclic.
▪ If precedence graph is acyclic, the serializability
order can be obtained by a topological sorting of the
graph.

▪ Recoverable schedule — if a transaction Tj reads a

data item previously written by a transaction Ti ,
then the commit operation of Ti appears before the
commit operation of Tj.
▪ The following schedule (Schedule 11) is not
recoverable

▪ If T8 should abort, T9 would have read (and possibly

shown to the user) an inconsistent database state.
Hence, database must ensure that schedules are
recoverable.

▪ Cascading rollback – a single transaction failure

leads to a series of transaction rollbacks. Consider
the following schedule where none of the
transactions has yet committed (so the schedule is
recoverable)
▪
If T10 fails, T11 and T12 must also be rolled back.
▪ Can lead to the undoing of a significant amount of
work

▪ Cascadeless schedules — cascading rollbacks cannot

occur;
• For each pair of transactions Ti and Tj such that
Tj reads a data item previously written by Ti, the
commit operation of Ti appears before the read
operation of Tj.
▪ Every Cascadeless schedule is also recoverable
▪ It is desirable to restrict the schedules to those that
are cascadeless
#Concurrency Control vs. Serializability Tests
▪ Concurrency-control protocols allow concurrent
schedules, but ensure that the schedules are
 conflict/view serializable, and are recoverable and
cascadeless .
▪ Concurrency control protocols (generally) do not
examine the precedence graph as it is being created
• Instead a protocol imposes a discipline that
avoids non-serializable schedules.
▪ Different concurrency control protocols provide
different tradeoffs between the amount of
concurrency they allow and the amount of overhead
that they incur.
▪ Tests for serializability help us understand why a
concurrency control protocol is correct.
#Weak Levels of Consistency
• ., a read-only transaction that wants to get an
approximate total balance of all accounts
• E.g., database statistics computed for query
optimization can be approximate (why?)
• Such transactions need not be serializable with
respect to other transactions
 #Transaction Definition in SQL
▪ In SQL, a transaction begins implicitly.
▪ A transaction in SQL ends by:
• Commit work commits current transaction and
begins a new one.
• Rollback work causes current transaction to
abort.
▪ In almost all database systems, by default, every SQL
statement also commits implicitly if it executes
successfully
• Implicit commit can be turned off by a database
directive
▪ E.g., in JDBC --
connection.setAutoCommit(false);
▪ Isolation level can be set at database level
▪ Isolation level can be changed at start of transaction
▪ E.g. In SQL set transaction isolation level
serializable
▪ E.g. in JDBC --
connection.setTransactionIsolation(
Connection.TRANSACTION_SERIALIZABLE)