Chapter 15:

Transactions
Loc Hoang
CS 157B
Definition

A transaction is a discrete unit of
work that must be completely
processed or not processed at all.

Example: Transferring funds from
a checking account to a saving
account.
Desirable Properties

To ensure data data integrity. The
database system must maintain
the ACID properties.


Atomicity

Consistency

Isolation

Durability
ACID continue…

Atomicity. Either all operations of the
transaction are reflected properly in
the database, or none are.


Consistency. Execution of a
transaction in isolation (that is, with no
other transaction executing
concurrently) preserves the
consistency of the database.
ACID continue...

Isolation. Even though multiple
transactions may execute concurrently,
the system guarantees that, for every pair
of transactions Ti, and Tj, it appears to Ti,
that either Tj finished execution before Ti
started, or that Tj started execution after
Ti finished. Thus, each transaction is
unaware of the transactions executing
concurrently in the system.
ACID continue...

Durability. After a transaction
completes successfully, the
changes it has made to the
database persist, even if there are
system failures.
Transaction States

Because failures occurs, transaction are
broken up into states to handle various
situation.
Transaction States

Active, the initial state; the
transaction stays in this state until
while it is still executing.


A transition is terminated only if it
has either been committed or
aborted.
Transaction States

Partially committed, After the
final statement has been executed


At this point failure is still possible
since changes may have been only
done in main memory, a hardware
failure could still occur.
Transaction States

The DBMS needs to write out
enough information to disk so that,
in case of a failure, the system
could re-create the updates
performed by the transaction once
the system is brought back up.
After it has written out all the
necessary information, it is
committed.
Transaction States

Committed- after successful
completion.

Once committed, the transaction
can no longer be undone by
aborting it.

Its effect could be undone only by
a compensating transaction.
Transaction States

Failed, after the discovery that
normal execution can no longer
proceed


Once a transaction can not be
completed, any changes that it
made must be undone rolling it
back.
Transaction States

Aborted, after the transaction has been
rolled back the the database has been
restored to its state prior to the start of the
transaction.


The DBMS could either kill the transaction or
restart the transaction.

A transaction may only be restarted as a
result of some hardware or software error,
and a restarted transaction is considered a
new transaction.
Concurrent execution

DBMS usually allow multiple
transaction to run at once.


The transaction could by run
serially (one after another) or they
could be interleaved(switching
back and forth between
transactions)
Concurrent execution

Pro:

Improved throughput and resource
utilization
Could take advantage of multi-processsing


Reduce waiting time.
Avoid short transaction waiting on long transaction
Improve average response time.
Concurrent execution

Con:

Creates many complications in
data consistency, including
cascading roll-backs.


Consistency could be compromise
even if each individual transaction
is correct.
Schedules

DBMS needs to make sure that all
transaction schedules preserves
the consistency of the database.


A schedule is the chronological
order in which instructions are
executed in a system.
Schedule

A schedule for a set of transaction
must consist of all the instruction of
those transaction and must
preserve the order in which the
instructions appear in each
individual transaction.
Schedule example
T1 T2
----------------- -----------------
read(A)
A:=A-50
write(A)
read(B)
B:= B+ 50
write(B)
read(A)
temp: A * 0.1
A: A-temp
write (A)
read(B)
B:=B +temp
write(B)

Schedule 1.
Serial Schedule

In schedule 1 the all the instructions of
T1 are grouped and run together. Then
all the instructions of T2 are grouped
and run together. This type of schedules
are called serial.


Concurrent transactions do not have to
run serially as in the next examples.
 Interleaved Schedule
T1 T2
----------------- -----------------
read(A)
A:=A-50
write(A)
read(A)
temp: A * 0.1
A: A-temp
write (A)
read(B)
B:= B+ 50
write(B)
read(B)
B:=B +temp
write(B)

Schedule 2
Conflict Equivalent

Schedule 1 and 2 produce the same
result even though they have different
sequence. It could be shown that
Schedule 2 could be transform into
Schedule 1 with a sequence of swaps,
so Schedule 1 and 2 conflict equivalent.


Not all schedules are conflict equivalent.
Consider Schedule 3
Inconsistent Schedule T2
T1
----------------- -----------------
read(A)
A:=A-50
read(A)
temp: A * 0.1
A: A-temp
write (A)
read(B)
write(A)
read(B)
B:= B+ 50
write(B)
B:=B +temp
write(B)

Schedule 3.
Serializability

Suppose that A and B were bank accounts
with initial amounts of $1,000 and $2,000
respectively. Then after Schedule 1 and
Schedule 2 are run. The result is $850 for
A and $2,150 for B. And the sum A+B is
still $3000.


After Schedule 3 runs, account A is $950
and B $2100. The sum A+B is now $3,050
which is incorrect, since $50 was magically
created in the process.
Conflict Serializability

Schedule 2 is consistent because is it
conflict equivalent to Schedule 1. Since
Schedule 1 is serial, Schedule two is said
to be conflict serializable.



Instructions within a schedule could be
swapped if they do not conflict. Instructions
do not conflict if they access different data
item or if they access the same data item
non of the instructions are write
instructions.
Conflict Serializability

Schedule 2 could be turn into Schedule 1
with the by the following steps:


Swap write(A) of T2 with read(B) of T1

Swap read(B) of T1 with read(A) of T2

Swap write(B) of T1 with write(A) of T2

Swap write(B) of T1 with read(A) of T2