- General definition of
serializability:
- S is
serializable iff:
- For every DB state: the effect of the execution of S is identical/equivalent to some serial schedule
- S is
serializable iff:
- Fact:
- The general definition of serializability is difficult to apply (= detect, verify)...
- We have therefore
define different kinds of
serializability that are
more practical
(= easier to
detect):
- Conflict-serializability
- based on the concept of
conflicting operations
(This type of serializability can be easily enforced by locks)
- based on the concept of
conflicting operations
- View-serializability
- based of the
concept of
view
(= what did the
transaction "see" (read))
(This type of serializability is more general but harder to enforce)
- based of the
concept of
view
(= what did the
transaction "see" (read))
- Conflict-serializability
- Fact:
- The most common form
of serializability
implemented in
DMBS is:
- Conflict-serializability
- The most common form
of serializability
implemented in
DMBS is:
- Conflicting operations:
- 2 consecutive operations in
a schedule S:
S = ..... op1 op2 .......is conflicting iff
- the behavior/result of at least one operation is changed when their order is interchanged
- 2 consecutive operations in
a schedule S:
- The basic operations
used by transactions to
operate on the
database are:
- Read( • )
- Write( • )
- Fact:
- A read(•) and
write(•) operation
can operate:
- On the same database elements
- On different database elements
- A read(•) and
write(•) operation
can operate:
- There are 6 possible
interactions
between
2 transactions
Ti and Tj
using the
basic database access operations:
- Ti: read(X) and Tj: read(Y)
- Ti:
read(X)
and
Tj:
read(X)
- Ti: read(X) and Tj: write(Y)
- Ti:
read(X)
and
Tj:
write(X)
- Ti: write(X) and Tj: write(Y)
- Ti: write(X) and Tj: write(X)
- The interaction of
2 basic operations is
non-conflicting if:
- The ordering of the execution of the basic operation does not affect the outcome
(Otherwise, the operations are conflicting)
- Outcome of the
basic operations:
- For a read(•) operation:
- The outcome = the return value of the read operation
- For a write(•) operation:
- The outcome = the final value of the database element that is written
- For a read(•) operation:
- Case 1:
ri(X) ;
rj(Y)
vs.
ri(X) ;
rj(Y)
- Behavior:
Behavior is identical because
-
ri(X)
and
rj(Y)
will return (= read) the
same value
- The values of DB elements X and Y are same at the end
-
ri(X)
and
rj(Y)
will return (= read) the
same value
- Behavior:
- Case 2:
ri(X) ;
rj(X)
vs.
rj(X) ;
ri(X)
- Behavior:
Behavior is identical because
-
ri(X)
and
rj(X)
will return (= read) the
same value
- The value of DB element X is same at the end
-
ri(X)
and
rj(X)
will return (= read) the
same value
- Behavior:
- Case 3:
ri(X) ;
wj(Y)
vs.
wj(Y) ;
ri(X)
- Behavior:
Behavior is identical because
-
ri(X)
will read the
same value
- The values of DB elements X and Y are same at the end
-
ri(X)
will read the
same value
- Behavior:
- Case 4:
ri(X) ;
wj(X)
vs.
wj(X) ;
ri(X)
- Behavior:
- Behavior is
different because
- ri(X) will return different values for different ordering of the operations !!!
- Behavior:
- Case 5:
wi(X) ;
wj(Y)
vs.
wj(Y) ;
wi(X)
- Behavior:
Behavior is identical because
- The values of DB elements X and Y are same at the end
- Behavior:
- Case 6:
wi(X) ;
wj(X)
vs.
wj(X) ;
wi(X)
- Behavior of
wi(X) ;
wj(X)
- Behavior is
different because
- The value of
DB elements
X
is different at the
end for
different ordering of
the operations
(I.e.: the transaction ordering matters !!!)
- The value of
DB elements
X
is different at the
end for
different ordering of
the operations
- Behavior of
wi(X) ;
wj(X)
- The trivial conflict:
- Read/write operations within
a transaction
will be executed in
a certain order
- We assume that the ordering of read/write within one transaction is fixed and cannot be altered
I.e.:
- Operations from the same transaction can not be executed in a different order
- Read/write operations within
a transaction
will be executed in
a certain order
- Therefore:
- 2 operations of the same transaction always conflict
I.e.: these combinations:
- Ti: read(X) and Ti: read(Y)
- Ti:
read(X)
and
Ti:
read(X)
- Ti: read(X) and Ti: write(Y)
- Ti:
read(X)
and
Ti:
write(X)
- Ti: write(X) and Ti: write(Y)
- Ti: write(X) and Ti: write(X)
are all conflicting operations
- Conflicting operations:
- 2 actions from the
same transaction
are conflicting:
ri( ... ) ; ri( ... ) ri( ... ) ; wi( ... ) wi( ... ) ; ri( ... )
- 2 actions from
different transactions are
conflicting if
- They operate on the same DB element
- One of the operation is write
Schematically:
1. ri(X) ; wj(X) 2. wi(X) ; wj(X)
- 2 actions from the
same transaction
are conflicting:
- Fact:
- If 2 operations
op1 and
op2
are
non-conflicting, we can:
- Re-order their
execution order in
a schedule and:
- the result of the new order of execution will be equivalent to the original order (starting in any database state)
- Re-order their
execution order in
a schedule and:
We can use swapping of non-conflicting operations to obtain a serial schedule !!!
- If 2 operations
op1 and
op2
are
non-conflicting, we can:
- Recall the
definition
of serializability:
- Schedule S is
serializable if:
- The effect of the execution of schedule S is idential to a serial schedule
- Schedule S is
serializable if: