S02 AdvDB Concepts 2

Lecture Lecture 2 2
Introduction to Transaction Processing Introduction to Transaction Processing

Concepts and Theory (cont.) Concepts and Theory (cont.)
Faculty of Science and Technology Advanced Database 2/39
Objectives
Objectives
Introduction to Transaction Processing
Transaction and System Concepts
Desirable Properties of Transactions
Characterizing Schedules based on Recoverability
Characterizing Schedules based on Serializability
Transaction Support in SQL
Reference: Chapter 21
Conflicting Instructions
Conflicting Instructions
Instructions l
i
and l
j
of transactions T
i
and T
j
respectively, conflict if
and only if there exists some item Q accessed by both l
i
and l
j
, and
at least one of these instructions wrote Q.
l
i
= write(Q)
l
i
= write(Q)
l
i
= read(Q)
l
i
= read(Q)
l
j
= write(Q)
l
j
= read(Q)
l
j
= write(Q)
l
j
= read(Q)
They conflict 4.
They conflict 3.
They conflict 2.
l
i
and l
j
dont conflict 1.
Intuitively, a conflict between l
i
and l
j
forces a (logical)
temporal order between them.
If l
i
and l
j
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.
say that I
i
and I
j
conflict if they are operations by different transactions on the
same data item, and at least one of these instructions is a write operation.
Conflict Equivalent Schedules
Conflict Equivalent Schedules
Two operations have a potential conflict if they belongs to two
different transactions, they perform operations on the same
data item and at least one of the operations is a write
operation. In such cases, the order of operations affects the
result. Conversely, if two operations in a schedule don't
conflict, we can swap their order without affecting the overall
result.
Two schedules are conflict equivalent, if the order of any two
conflicting operations is the same in both schedules
A schedule S is conflict serializable if it is conflict equivalent
to some serial schedule S
In practice, if we can transform a schedule by swapping the
orders of two consecutive non-conflicting operations such
that the result is a serial schedule then we say that the
schedule is conflict serializible
Conflict Equivalent
Conflict Equivalent
Serial Schedule S
1
order
doesnt matter
read_item(A):
write_item(A);
read_item(B);
write_item(B);
read_item(A);
write_item(A);
read_item(B);
write_item(B);
T
2
T
1
order matters
order doesnt matter
order matters
Conflict Equivalent
Conflict Equivalent
(2)
(2)
Schedule S
1
S
1
and S
1
are conflict equivalent
(S
1
produces the same result as S
1
)
read_item(B);
write_item(B);
write_item(B);
read_item(A):
write_item(A);
read_item(A);
write_item(A);
read_item(B);
T
2
T
1
same order as in S1
same order as in S1
Conflict Equivalent
Conflict Equivalent
(3)
(3)
Schedule S
1
Schedule S
1
is not conflict equivalent to S
1
(produces a different result than S
1
)
read_item(B);
write_item(B);
read_item(B);
write_item(B);
read_item(A);
write_item(A);
read_item(A):
write_item(A);
T
2
T
1
different order as in S1
different order as in S1
Other Example
Other Example
Schedule S can be transformed into Schedule S, a serial
schedule where T
2
follows T
1
, by series of swaps of non-
conflicting instructions.
Therefore Schedule S is conflict serializable.
S S
write(A) of T1
and read(A) of
T2 are conflict
but write(A) of
T2 is not
conflict with
read(B) of T1.
read(A)
write(A)
read(B)
write(B)
read(A)
write(A)
read(B)
write(B)
T
2
T
1
read(A)
write(A)
read(B)
write(B)
read(A)
write(A)
read(B)
write(B)
T
2
T
1
Swappings step by step in

schedule S to produce a
serial schedule.
Swap the write(A) of T
2
with
read(B) of T
1
read(A)
write(A)
read(B)
write(B)
read(A)
write(A)
read(B)
write(B)
T
2
T
1
Swap the read(B) of T

1
with
read(A) of T
2
read(A)
write(A)
read(B)
write(B)
read(A)
write(A)
read(B)
write(B)
T
2
T
1
Swap the write(B) of T

1
with
write(A) of T
2
read(A)
write(A)
read(B)
write(B)
read(A)
write(A)
read(B)
write(B)
T
2
T
1
Swap the write(B) of T

1
with
read(A) of T
2
read(A)
write(A)
read(B)
write(B)
read(A)
write(A)
read(B)
write(B)
T
2
T
1
Conflict
Conflict
Serializable
Serializable
Schedule S is conflict serializable if it is conflict
equivalent to some serial schedule S
Can reorder the non-conflicting operations to improve
efficiency
Non-conflicting operations:
Reads and writes from same transaction
Reads from different transactions
Reads and writes from different transactions on
different data items
Conflicting operations:
Reads and writes from different transactions on same
data item
Example
Example
B is conflict equivalent to A B is serializable
read_item(Y
);
Y:=Y+N;
write_item(Y
);
read_item(X
);
X:=X+M;
write_item(X
);
read_item(X
);
X:=X+M;
write_item(X
);
read_item(Y
);
Y:=Y+N;
write_item(Y
);
read_item(X
);
X:=X-N;
write_item(X
);
read_item(X
);
X:=X-N;
write_item(X
);
T
2
T
1
T
2
T
1
Schedule A Schedule B
Test for
Test for
Serializability
Serializability
Construct a directed graph, precedence graph, G = (V, E)
V: set of all transactions participating in schedule
E: set of edges T
i
T
j
for which one of the following holds:
T
i
executes a write_item(X) before T
j
executes read_item(X)
T
i
executes a read_item(X) before T
j
executes write_item(X)
T
i
executes a write_item(X) before T
j
executes write_item(X)
An edge T
i
T
j
means that in any serial schedule equivalent
to S, T
i
must come before T
j
If G has a cycle, than S is not conflict serializable
If not, use topological sort to obtain serialiazable schedule
(linear order consistent with precedence order of graph)
Sample Schedule S
Sample Schedule S
T1 T2
T3
X,Y
Y
Y,Z
no cycles S is serializable
Equivalent Serial Schedule:
T3 T1 T2
(precedence order)
read_item(Y);
read_item(Z);
write_item(Y);
write_item(Z);
read_item(Z);
read_item(Y);
write_item(Y);
read_item(X);
write_item(X);
read_item(X);
write_item(X);
read_item(Y);
write_item(Y);
T
3
T
2
T
1
Examples of serial and
Examples of serial and
nonserial
nonserial
schedules
schedules
(a) Serial Schedule A: T
1
followed by T
2
(b) Serial Schedule B: T
2
followed by T
1
Examples
Examples
(2)
(2)
(c) Two nonserial schedules C and D with interleaving of
operations
Constructing the Precedence
Constructing the Precedence
Graphs
Graphs
Another example of Another example of serializability serializability testing testing
(a) The READ and WRITE operations of three
transactions T
1
, T
2
, and T
3
.
(2) (2)
Schedule E
(3) (3)
Schedule F
Characterizing Schedules based on
Recoverability
Recoverability
Transaction schedule or history:
When transactions are executing concurrently in an interleaved
fashion, the order of execution of operations from the various
transactions forms what is known as a transaction schedule (or
history).
A schedule (or history) S of n transactions T
1
, T
2
, ..., T
n
:
It is an ordering of the operations of the transactions subject to
the constraint that, for each transaction T
i
that participates in S,
the operations of T
1
in S must appear in the same order in
which they occur in T
1
.
Note, however, that operations from other transactions T
j
can
be interleaved with the operations of T
i
in S.
Recoverability (2)
Recoverability (2)
Schedules classified on recoverability:
Recoverable schedule:
One where no transaction needs to be rolled back.
A schedule S is recoverable if no transaction T in S commits until all
transactions T that have written an item that T reads have committed.
S
c
: r
1
(X); w
1
(X); r
2
(X); r
1
(Y); w
2
(X); c
2
; a
1
;
S
d
: r
1
(X); w
1
(X); r
2
(X); r
1
(Y); w
2
(X); w
1
(Y); c
1
; c
2
;
read(A)
commit
read(A)
write(A)
read(B)
abort
commit
T
2
T
1
Suppose that the system allows T
2
to
commit immediately
after executing the read(A) instruction.
Thus, T
2
commits before T
1
does. Now
suppose that T
1
fails before it commits.
Since T
2
has read the value of data item A
written by T
1
, we must abort T
2
to ensure
transaction atomicity. However, T
2
has
already committed and cannot be aborted.
Recoverability (3)
Recoverability (3)
Cascading rollback schedule (or Cascadeless):
A schedule in which uncommitted transaction that read an item from a
failed transaction must be rollback.
S
e
: r
1
(X); w
1
(X); r
2
(X); r
1
(Y); w
2
(X); w
1
(Y); a
1
; a
2
;
read(A)
write(A)
commit
T
2
read(A)
commit
read(A)
read(B)
write(A)
abort
commit
T
3
T
1
Suppose that, at this point,
T
1
fails T
1
must be rolled back.
Since T
2
is dependent on T
1
T
2
Since T
3
is dependent on T
2
T
3
Recoverability
Recoverability
(4)
(4)
Cascadeless Schedule:
One where every transaction reads only the items that are written by
committed transactions.
S
d
: r
1
(X); w
1
(X); r
1
(Y); w
2
(X); w
1
(Y); c
1
; r
2
(X); c
2
;
write(X)
read(X)
commit
read(X)
write(X)
read(Y)
write(Y)
commit
T
2
T
1
r
2
(X) is written by c
1

Cascadeless schedule
Recoverability
Recoverability
(5)
(5)
Strict Schedules:
A schedule in which a transaction can neither read or write an item X
until the last transaction that wrote X has committed.
Any strict schedule is cascadeless, but not the converse
write(X)
read(X)
commit
read(X)
write(X)
read(Y)
write(Y)
commit
T
2
T
1
c
1
not precedes w
2
(X)
None strict schedule
Cascadeless schedule
Serializability
Serializability
Being serializable is not the same as being serial
Being serializable implies that the schedule is a
correct schedule.
It will leave the database in a consistent state.
The interleaving is appropriate and will result in a
state as if the transactions were serially executed, yet
will achieve efficiency due to concurrent execution.
Serializability is hard to check.
Interleaving of operations occurs in an operating
system through some scheduler
Difficult to determine beforehand how the operations
in a schedule will be interleaved.
Serializability
Serializability
(2)
(2)
Practical approach:
Come up with methods (protocols) to ensure serializability.
Its not possible to determine when a schedule begins and
when it ends.
Hence, we reduce the problem of checking the whole schedule
to checking only a committed project of the schedule (i.e.
operations from only the committed transactions.)
Current approach used in most DBMSs:
Use of locks with two phase locking
Serializability
Serializability
(3)
(3)
View equivalence:
A less restrictive definition of equivalence of
schedules in compare with conflict equivalence.
View serializability:
Definition of serializability based on view equivalence.
A schedule is view serializable if it is view equivalent
to a serial schedule.
Serializability
Serializability
(5)
(5)
The same set of transactions participates in both schedules
Two schedules are said to be view equivalent if the
following three conditions hold:
1. if T
j
reads the initial value of X in S, then it also reads the
initial value of X in S'
2. if T
j
reads X in S and X was produced by T
k
, then T
j
must also
read the value of X produced by T
k
in S'
3. if T
j
performs the final write of X in S, then it must also
perform the final write of X in S'
Conditions 1 and 2 ensure that each transaction reads the same values in
both schedules and, therefore, performs the same computation. Condition
3, coupled with conditions 1 and 2, ensures that both schedules result in
the same final system state.
Serializability
Serializability
(6)
(6)
The premise behind view equivalence:
As long as each read operation of a transaction
reads the result of the same write operation in both
schedules, the write operations of each transaction
must produce the same results.
The view: the read operations are said to see the
same view in both schedules.
Serializability
Serializability
(7)
(7)
Relationship between view and conflict equivalence:
The two are same under constrained write assumption
which assumes that if T writes X, it is constrained by the
value of X it read; i.e., new X = f(old X)
Conflict serializability is stricter than view serializability. With
unconstrained write (or blind write), a schedule that is view
serializable is not necessarily conflict serialiable.
Any conflict serializable schedule is also view serializable,
but not vice versa.
Serializability
Serializability
(8)
(8)
Relationship between view and conflict equivalence (cont):
Consider the following schedule of three transactions
T
1
: r
1
(X), w
1
(X); T
2
: w
2
(X); and T
3
: w
3
(X):
Schedule S
a
: r
1
(X); w
2
(X); w
1
(X); w
3
(X); c
1
; c
2
; c
3
;
In S
a
, the operations w
2
(X) and w
3
(X) are blind writes, since T
1
and T
3
do not read the value of X.
S
a
is view serializable, since it is view equivalent to the serial
schedule T
1
, T
2
, T
3
. However, S
a
is not conflict serializable,
since it is not conflict equivalent to any serial schedule.
Blind writes appear in any view-serializable schedule that is not conflict serializable.
Every conflict-serializable schedule is also view serializable,
but there are view serializable schedules that are not conflict-serializable
Example: View
Example: View
Serializability
Serializability
Conflict Serializability
Equivalent to T
1
T
2
read(A)
write(A)
read(A)
write(A)
read(B)
write(B)
T
2
T
1
View Serializability
Equivalent to T
3
T
4
T
5
write(Q)
T
4
write(Q)
read(Q)
write(Q)
T
5
T
3
Is it view serializable?
Yes
Is it conflict serializable?
No
Example: View
Example: View
Serializability
Serializability
(2)
(2)
Every conflict serializable schedule is also view serializable,
but not vice versa.
The following is view serializable but not conflict serializable
write(Q)
T
4
write(Q)
read(Q)
write(Q)
T
5
T
3
This view serializable
schedule has blind writes.
All view serializable schedules strictly contain conflict
serializable schedules.
Example: View
Example: View
Serializability
Serializability
(3)
(3)
All schedules equivalent to a serial schedule strictly contain view
serializable schedules.
read(B)
B=B-50
write(B)
read(A)
A=A+10
write(A)
read(A)
A=A-50
write(A)
read(B)
B=B+50
write(B)
T
2
T
1
It is equivalent to schedule
<T
1
,T
2
>, yet is not view
serializable or conflict
serializable.
Hierarchical relationship between
serializability
serializability
classes
classes
Serial conflict-serializable view-serializable all
schedules
Serial strict avoids cascading aborts
recoverable all schedules
Practical implementations
In practice, most businesses aim for conflict-
serializable and recoverable (primarily strict)
schedules.
serializability
serializability
classes (2)
classes (2)
Transaction Support in
Transaction Support in
SQL2
SQL2
A single SQL statement is always considered to be atomic.
Either the statement completes execution without error or it fails
and leaves the database unchanged.
With SQL, there is no explicit Begin Transaction statement.
Transaction initiation is done implicitly when particular SQL
statements are encountered.
Every transaction must have an explicit end statement,
which is either a COMMIT or ROLLBACK.
Transaction Support in SQL2 (2)
Characteristics specified by a SET TRANSACTION
statement:
Access mode:
READ ONLY or READ WRITE.
The default is READ WRITE unless the isolation level of READ
UNCOMITTED is specified, in which case READ ONLY is
assumed.
Diagnostic size n, specifies an integer value n, indicating
the number of conditions that can be held simultaneously in
the diagnostic area.
These conditions supply feedback information (errors or
exceptions) to the user or program.
Characteristics specified by a SET TRANSACTION
statement (Contd.):
Isolation level <isolation>, where <isolation> can be READ
UNCOMMITTED, READ COMMITTED, REPEATABLE
READ or SERIALIZABLE.
The default is SERIALIZABLE.
With SERIALIZABLE: the interleaved execution of transactions
will adhere to our notion of serializability.
However, if any transaction executes at a lower level, then
serializability may be violated.
Potential problem with lower isolation levels:
Dirty Read:
Reading a value that was written by a transaction which failed.
Nonrepeatable Read:
Allowing another transaction to write a new value between
multiple reads of one transaction.
A transaction T
1
may read a given value from a table. If
another transaction T
2
later updates that value and T
1
reads
that value again, T
1
will see a different value.
Consider that T
1
reads the employee salary for Smith.
Next, T
2
updates the salary for Smith.
If T
1
reads Smith's salary again, then it will see a different value for
Smith's salary.
Potential problem with lower isolation levels (Contd.):
Phantoms:
New rows being read using the same read with a condition.
A transaction T
1
may read a set of rows from a table, perhaps
based on some condition specified in the SQL WHERE clause.
Now suppose that a transaction T
2
inserts a new row that also
satisfies the WHERE clause condition of T
1
, into the table used by
T
1
.
If T
1
is repeated, then T
1
will see a row that previously did not
exist, called a phantom.
Exercise(1): Transactions
Consider the following schedule consisting for four
transaction T
1
, T
2
, T
3
, and T
4
:
S: r
1
(X); w
1
(X); r
2
(X); r
3
(Y); w
3
(Y); w
2
(X); r
4
(Y); w
1
(Y);
c
1
; c
2
; c
4
; c
3
Question:
a). Show that the schedule is conflict serializable by
constructing the precedence graph.
b). What is the equivalent serial schedule?
c). Rewrite the schedule so it becomes recoverable.
Exercise(1): Solution
Answer:
S: r
1
(X); w
1
(X); r
2
(X); r
3
(Y); w
3
(Y); w
2
(X); r
4
(Y); w
1
(Y); c
1
;
c
2
; c
4
; c
3
Consider the following schedule consisting for four
transaction T
1
, T
2
and T
3
:
S: r
3
(Z); w
3
(Z); r
1
(X); r
2
(Y); w
2
(Y); w
1
(X); r
1
(Y); r
3
(X);
c
1
; c
2
; c
3
Question:
Answer:
S: r
3
(Z); w
3
(Z); r
1
(X); r
2
(Y); w
2
(Y); w
1
(X); r
1
(Y); r
3
(X); c
1
; c
2
;
c
3
a). Show that the schedule is conflict serializable by constructing
the precedence graph.

S02 AdvDB Concepts 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

S02 AdvDB Concepts 2

Uploaded by

Copyright:

Available Formats

Lecture Lecture 2 2

Introduction to Transaction Processing Introduction to Transaction Processing

Swappings step by step in

Swap the read(B) of T

Swap the write(B) of T

Swap the write(B) of T

You might also like