Introduction to

Real-Time Databases

[email protected]

(Embedded Systems and Wireless Networking Laboratory)

Reading:
Kam-yiu Lam and Tei-Wei Kuo, Real-Time Database Systems: Architecture and Techniques, Kluwer Academic Publishers, 2000
1
Krishna and Kang, Real-TimeSystems, McGRAW-HILL, 1997.

Introduction

An Informal Definition of Real-Time Databases:

A real-time database system is a database
system in which a timely response to a user
request is needed.
Types of Real-Time Database Systems:
Hard real-time database systems, e.g., safety-critical
system such as an early warning system, etc.
Soft real-time database systems, e.g., banking system,
airline reservation system, digital library, stock market
system, etc.
Mixed real-time database systems, e.g., air traffic
control system, etc.
2

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Introduction

Types of Real-Time Transactions

Hard real-time transactions

value

No deadline violation

Soft real-time transactions

deadline

value

Low miss ratio or

avg/worst-case response time

deadline

Firm real-time transactions

No value after deadlines expire.

value
deadline
3

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Introduction

Design Issues
Real-Time Concurrency Control
Optimistic vs Conservative CC
Index

Run-Time System Management

Recovery
Buffer Management
Disk Scheduling

Distributed RTDBMS
Data Replication
Commit Processing
Mobile RTDBMS

etc
4
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Introduction to Real-Time Database

Checklist
What should we really know about the design issues of
real-time databases?
What is known about concurrency control of real-time
data access?
What is known about real-time recovery?
Why is it so hard to have response-time predictability?
What is main-memory database? Is it useful to RTDB?
What is known about real-time query optimization?
What is known about availability issues, real-time file
systems, and disk management?
5

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Introduction to Real-Time Database

Time
Model and Design

Concurrency Control (CC)

(Son, Ramaritham, Lin, Bestavos, Wolfe,
Garcia-Molina, Mok, Kuo, Lam, Zhao,
Sha, etc, since early 1980)

(Son, Lin, Singhal, Mok, Kuo,

Dayal,Ramaritham, Stankovic,
since early 1980)

Weak Correctness Criteria

CC Based on
(Mok, Kuo, Pu, Ramaritham,
Simulation
Lin, etc, since mid 1980)
.
Complex CC
Fault Tolerance &
.
CC Based on
Availability
Application Semantics
Query Optimization
(Lin, 1988 & ....)
.
(Wolfe, etc, since early 1990)
CC of Mixed RT Transactions
.
Active + RTDB
Recovery and Logging
CC + Recovery
(Son,
Mok,
Lam, since 1996)
(Ramaritham,Lam, since 1996)
.

File Structure &

Data Caching
(??)
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Commercial Database &

Realistic Workloads
(??)
6

Introduction to Real-Time Database

Real-Time vs. General Purpose Databases
Basic Definitions & ACID Properties
Correctness Criteria
Consistency Constraints
Needs for Response-Time Predictability
Main Memory Database for RTDB
7

Basic Definitions & ACID Properties

A transaction is a sequence of read and write

operations, i.e., r(x) and w(y). (transaction instance)
A history/schedule over a set of transactions is
an interleaving of the read and write operations
issued by the transactions , e.g.,
w2(x),r1(x),w2(y),r1(y).
A query transaction consists of only read
operations. (vs update)
A serial schedule is a sequence of operations
which are issued by transactions one by one, e.g.,
w2(x), w2(y), r1(x), r1(y).
8

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Data Access versus Semaphore

Locking

Typical Schedule
T1 (x=x-100, y=y+100)
r(x)
w(x)

T2

r(x)
r(y)
r(y)
w(y)
9
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Basic Definitions & ACID Properties

In conventional databases, transactions

must satisfy the ACID properties:
Atomicity: all or nothing.
Consistency: consistent transformation of DB
states.
Isolation: invisibility for dirty data. (degrees)
Durability: permanent committed updates.

In real-time databases, relaxing ACID

depends on application semantics.
10

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Correctness Criteria

Conventional Criteria:
Final-State Serializability ~ NP-hard
Generate the same final state as a serial schedule does.

View Serializability ~ NP-hard

Final-State Serializability, and
Corresponding transactions have the same view over the
database.

Conflict Serializability ~ Polynomial

The order of conflicting operations is the same as that of a
serial schedule.

Criteria for Real-Time Databases:

Weak criteria are possible, but their definitions depend on

application semantics.
Reading: C. Papadimitriou, The theory of Database Concurrency Control, Computer Science Press, 1986.

11

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Examples: Serializability
S = R1(X)W1(X) R2(X)R2(Y)W2(Y) W1(Y)
S is final-state equivalent to S1 = 2 1
S is not view equivalent to S1 because of the transaction
view of 2, which is a dead transaction.
S = R1(Y) R3(W) R2(Y) W1(Y)W1(X) W2(X)W2(Z) W3(X)
S is view equivalent to S1 = 2 1 3.
1
Y
S is not conflict equivalent to S1
X
X
because of the order of the two dead
2
W(X)s of 1 and 2.
3
X

12

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Correctness Criteria - Relaxing...

An Airline Reservation Example1

Rules:
Reservation:
Reserve a seat.
If over 100 seats, assign 5 flight attendants to the flight;
otherwise assign 3 attendants.

Cancellation
Cancel a seat on the flight.
If the number of reservations drops below 85, assign only3
flight attendants to the flight.

Hysteresis: The assigned number will not oscillate rapidly.

Scenarios: Starting from 3 attendants from TPE to LA, and LA to AUS,
99 servations on each flight.
ReserveA(TPE,LA), CancelB(TPE,LA,), CancelB(LA,AUS), ReserveA(LA,AUS)
TPE-LA: 5 attendants, LA-AUS: 3, An acceptable but non-serializable schedule!
1 H. Garcia-Molina and K. Salem, Main Memory Database Systems: An Overview, IEEE Trans. Knowledge and Data Engineering, 4(6):509-516, 1992.

13

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Consistency Constraints

In conventional databases,
Internal Consistency
Database satisfies consistency and integrity constraints, e.g.,
x=y.

In real-time databases,timing properties of data are

important, too!
Absolute/External Consistency
Data reflect the changings of the external environment.
For example, stock index.

Relative/Temporal Consistency
The ages of two data are within a tolerable length of time.
For example, the temperature and the pressure of a boiler read
14
at time t.
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Needs for Response-Time Predictability

Why is it so hard to have response-time

predictability for disk-based or other databases?
Blocking and transaction abortings caused by the
requirement to meet the ACID properties.
Unpredictability of disk access time and page faults2.
Data dependency of transaction executions.

However, in many cases, we often only

use main memory database, or

need worst-case predictability, or
use real memory addressing, or
best effort in scheduling.
15

@ all rights
for Tei-Wei
Kuo,logging
National
Taiwan
University
Onlypreserved
bad for disk-based
databases,
purpose,
or virtual
memory usage.
2

Main Memory Database for RTDB

Why main memory databases?

Improve response time.
Reduce unpredictability of response time.
Critical factors of contentions:
transaction duration and lock granularity.

Hardware technology improvements.

What is the cost or research beside money?

Higher frequency in data backup.
Vulnerable to system failures - efficient logging
mechanism, recoverability, and recovery time to
transaction and system failures.
Different indexing schemes beside shallow B-tree.

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

16

Introduction to Real-Time Database

Concurrency Control
Conservative Concurrency Control
Optimistic Concurrency Control
Semantics-Based Concurrency Control
Concurrency Control for
Mixed Transaction Systems
17

Introduction to Real-Time Database

Issues for Real-Time Concurrency Control (RT-CC)

Data consistency and integrity.
Urgency of transaction executions.

General Approaches for RT-CC:

Integrate real-time techniques, e.g., RM, EDF, and PCP,
and traditional concurrency control protocols, e.g., 2PL,
OCC, RWPCP, Multiversion-CC.
Utilize application semantics to improve system
performance.
Adopt suitable software architectures such as an objectoriented design, etc.
18

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Introduction to Real-Time Database

Classification of RT-CC protocols:

Syntactic-based concurrency control
Conservative Mechanism
Prevention of any serializability violation in advance.
conservative in resource usages.

Significant blocking cost

Optimistic Mechanism
Three phases for each transaction execution:
read, validation, write

Significant aborting cost

etc

Semantics-based concurrency control

CC with flexibility in reordering read and write events.
Concurrency level vs worst-case blocking time.

CC with reduced and simplified CC protocols, e.g., single writer.

Such systems which totally satisfy requirements rarely exist.

etc.

19
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Syntactic-Based Concurrency Control

Pessimistic Concurrency Control

Ensure that transactions will not violate serializability
consistency during their executions
Q: How to favor high priority transactions, e.g., in the
processing of locking requests?

Optimistic Concurrency Control

Any violation of serializability consistency from a
transaction will not be checked until its validation time.
Q: How to favor high priority transactions if there exist
conflicts between high and low priority transactions?
20

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Lock-Oriented Concurrency Control

Characteristics
A typical way for pessimistic concurrency control
Prevention of serializability violation by lock
management - possibly lengthy blocking time

An Example Protocol
Two-phase locking + A Priority Assignment
Scheme, such as RM or EDF.
Two-phase locking growing phase and shrinking
phase
priority inheritance.

21

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Lock-Based Concurrency Control

Read/Write Priority Ceiling Protocol

(RWPCP)
2-Version RWPCP
Aborting versus Blocking

22
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Lock-Based Concurrency Control

Read/Write Priority Ceiling Protocol

(RWPCP)
2-Version RWPCP
Aborting versus Blocking

23
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Read/Write Priority Ceiling Protocol

Ceiling definitions of data object Oi

Write Priority Ceiling (WPLi) of Oi
Absolute Priority Ceiling (APLi) of Oi
Read/Write Priority Ceiling (RWPLi) of Oi
WPLi or APLi

Ceiling rule
A transaction may lock a data object if its
priority is higher than the highest RWPLi of
data objects locked by other transactions.
24

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

RWPCP
1

APL1 = 1
WPL1= 2
APL2 = 2
WPL2= 3

UL(S1)
RL(S1)

10

12

14

16

18

20

22

24

26

28

30

UL(S2)
WL(S1)

RL(S2)

10

UL(S1)

12

14

16

18

20

22

24

26

28

30

12

14

16

18

20

22

24

26

28

30

UL(S2)

WL(S2)

3
0

10

S1

S2

S1&S2
25

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Properties of RWPCP

Properties in Uniprocessor Environments

Lemma1: No transitive blocking (L->M->H)
Theorem 1: One priority inversion per
transaction.
Theorem 2 : Deadlock-freeness
Theorem 4: Serializable schedules if the twophase-locking scheme (2PL) is followed.

26
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

RWPCP in a Multiprocessor Environment

Processor 1

WL(S1)

UL(S1)

1
2

6
RL(S1)

10

10

12
UL(S1)

14

16

18

14

16

18

S1
S2

12

APL1 = 1
WPL1= 1
APL2 = 2
WPL2= null
APL3 = 2
WPL3= null

S3
RL(S2)

Processor 2

RL(S3)

UL(S3)

UL(S2)

2
2
RL(S1)

4
6
UL(S1)

10

12

14

16

18

10

12

14

16

18

4
2

Example 1 RWPCP Schedule

27
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

An Observation
The number of priority inversion may be
more than one when there are more
than one processor in the system!

28
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Why?

The priority gap between the priority of 2

and the read write priority ceiling of the
data objects locked by 2
Priority of 2
WPL(S2)

How to guarantee single priority inversion

time in a multiprocessor environment ?
Reference: Tei-Wei Kuo and Hsin-Chia Hsih, 2000, "Concurrency Control in a Multiprocessor Real-Time Database System,
the 12th Euromicro Conference on Real-Time Systems, Stockholm, Sweden, June 2000.

29
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Lock-Based Concurrency Control

Read/Write Priority Ceiling Protocol

(RWPCP)
2-Version RWPCP (2VPCP)
Aborting versus Blocking

30
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Two-Version Read/Write Priority

Ceiling Protocol
Objectives:
Reduce the blocking time of higher-priority
transactions
Dynamic Adjustment of Serializability Order

Lock Modes
Working/Consistent Versions
Writes on working versions
Reads from consistent versions

Read/Write/Certify Locks
31
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Two-Version Read/Write Priority

Ceiling Protocol

Ceiling definitions of data object Oi

Write Priority Ceiling (WPLi) of Oi
Absolute Priority Ceiling (APLi) of Oi
Read/Write Priority Ceiling (RWPLi) of Oi
WPLi for read/write locks or APLi for certify locks

Ceiling rule
A transaction may lock a data object if its
priority is higher than the highest RWPLi of
data objects locked by other transactions.
32

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Two-Version Read/Write Priority

Ceiling Protocol
A compatibility table for 2VPCP:
Requested locks
Read
Write
Granted Granted
Granted Blocked
Blocked
Blocked

Lock already set

Read
Write
Certify

Certify
Blocked
Blocked
Blocked

Remark:
More versions?
Aborting allowed?

33
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

2VPCP
1

RL(S1)

10

12

APL1 = 1
WPL1= 2
APL2 = 2
WPL2= 3

UL(S1)

14

16

18

20

22

24

26

28

30

26

28

30

28

30

UL(S2)
WL(S1) RL(S2)

UL(S1)

10

12

14

16

18

20

22

24

UL(S2)

WL(S2)

3
0

10

12

14

16

18

20

22

24

S1
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

26

S2

S1&S2
34

Properties of 2VPCP

Properties
Lemma1: No transitive blocking (L->M->H)
Theorem 1: One priority inversion per
transaction.
Theorem 2 : Deadlock-freeness
Theorem 4: Serializable schedules if the twophase-locking scheme (2PL) is followed.

35
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Simulation Results

Miss Ratios of All Transactions

* NPNP adopts multiple versions for a data object!
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

36

Simulation Results

Miss Ratios of the Top Priority Transactions

37
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Lock-Based Concurrency Control

Read/Write Priority Ceiling Protocol

(RWPCP)
2-Version RWPCP (2VPCP)
Aborting versus Blocking

38
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Basic Aborting Protocol (BAP)

Main Idea:
When a lower priority transaction introduces excessive
blocking to a higher priority transaction, then higher
priority transaction will abort the lower priority
transaction.

Compatible Modules:
Priority Ceiling Protocol (PCP)
2PL
A simple aborting mechanism

Reference: Tei-Wei Kuo, Ming-Chung Liang, and LihChyun Shu, Abort-Oriented Concurrency Control for Real-Time Databases,
IEEE Transactions on Computers (SCI), Vol. 50, No. 7, July 2001, pp. 660-673.

39

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

BAP Protocol Summary

Transactions are classified as abortable or non-abortable in

an off-line fashion.
Each transaction instance must acquire a semaphore before
access the corresponding data object.
Lock granted: when a transaction instance attempts to lock a
semaphore, it checks whether its priority is higher than the priority
ceiling of all semaphores already locked by other transaction instances.
Blocked: if there exists any non-abortable lower priority transaction
instance which locked a semaphore with a priority ceiling no less than
the priority of , then is blocked by , and inherits the priority of .
Aborting: Otherwise, is aborted, and the lock is granted.
40

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

BAP Schedule

TH ( 5,11)

TM (5,19)

TL ( 7,22)

41
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

PCP+2PL Schedule

TH (5,11)

TM (5,19)

TL ( 7,22)

42
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Properties

Lemma 1. BAP prevents deadlocks.

Theorem 1. Schedules generated by BAP are logically
correct (based on serializability).
Theorem 3. No transaction instance scheduled by BAP
directly or indirectly inherits a priority level from a
transaction instance which is aborted before commits or is
aborted.
Theorem 4. A transaction instance can experience at most
one time of priority inversion under BAP.
Theorem 5. A higher priority transaction instance can abort
at most one lower priority transaction instance under BAP.
43

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Schedulability Analysis

A-costi,j : maximum direct aborting cost of j charged by i

-costi,j : max(A-costi,k), where i < k <= j.
Lemma 2. The worst-case aborting cost for a request of transaction j
between time 0 and time t <= p is at most
j

t
(
i HPC j p cost i , j )
i
Lemma 3. A transaction i scheduled by BAP will always meet its

deadline for all process phases if there exists a pair

that

( k , m) Ri

such

mpk
) + ci + bi + abi mpk
p
j

(c j

jHPCi

where b and ab are the worst case blocking cost and aborting cost of
i
i
transaction i ,
p
Ri = {( k , m) 1 k i, m = 1, 2, ..., i }
pk

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

44

Schedulability Analysis Procedure

Lemma 3 shows that the maximum blocking time

that transaction i can tolerate is
MBi =

ab

i
i

p j

max t SPi t j HPC c j

Initially all transactions are non-abortable.

i=1
If i > n then stop
If transaction j has a priority ceiling no less than i
and the length of the critical section is larger than MBi ,
then j becomes abortable, where j > i.
i=i+1
45

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Extensions of BAP

Table-Driven Aborting Protocol (TAP)

Give a more fine-grained fashion of aborting
relationship
An instance of transaction i can abort an
instance of transaction j only when AB[i, j] =
yes.
The rest of the TAP is the same as BAP.
The properties of BAP remain.
46

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Extensions of BAP

Dynamic Aborting Protocol (DAP)

Run-Time Calculation of Tolerable Blocking Time:
The blocking time that an instance of a transaction can
tolerate is estimated dynamically and based on the
current workload instead of the worst case situation.

Run-Time Determination of Aborting Relationship:

An instance of a higher priority transaction H can abort
an instance of a lower priority transaction L at time t
only if (1)L blocks H, (2)L is abortable, and (3) the
maximum tolerable blocking time of H is less than the
possible blocking time of L at time t.
47
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

DAP: Approximate Schedulability Test

Theorem 8. A transaction i scheduled by DAP will

always meet its deadline for all process phases if
di
(
c j )+ c i + bi + abi d i
j HPC i p j

The maximum blocking time that transaction i can

tolerate at time t is approximated as:
where

AMB i = ( d i t )

di t
c j ) c i ab i ( t )
p

(
j HPC

di t
cost i , j )
p
i

abi ( t ) = HPC (
i
j

The rest of the DAP is the same as BAP.

The properties of BAP remain.

48
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Performance Evaluation

Case Study
Generic Avionics Platform
18 periodic transactions.
9 data objects.

Olympus AOCS
10 periodic transactions.
4 sporadic transactions.
17 data objects.

Simulation Experiment
Compare BAP, TAP, and DAP with the well known Priority
Ceiling Protocol (PCP), Rate Monotonic Scheduling
algorithm (RMS), and Abort Ceiling Protocol (ACP).
49

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Case Study 1: Generic Avionics Platform

50
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Schedulability Analysis: Generic Avionics Platform

* PCP + 2PL: Only the first two transactions are schedulable.

51

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

0.04

0.04

0.03

0.03

Miss Ratio

Miss Ratio

Simulation Results

0.02

0.01

0.02

0.01

0
40

45

50

55

60

65

70

75

80

85

90

95

40

PCP
DAP

BAP
ACP

45

50

55

60

65

70

75

80

85

90

95

System Load (%)

System Load (%)

T AP
RMS

Fig 4: T op 1/4 T ransactions, DB size = 25

PCP
BAP
T AP
DAP
ACP
RMS
Fig 5: T op 1/4 T ransactions, DB size = 50

52
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

0.04

0.03

0.03

Miss Ratio

0.04

0.02

0.01

0.02

0.01

0
40

45

50

55

60
65
70
75
System Load (%)

80

85

90

95

40

45

50

55

60

65

70

75

80

85

90

95

System Load (%)

PCP
DAP

BAP
ACP

T AP
RMS

PCP
BAP
T AP
DAP
ACP
RMS
Fig 7: T op 1/4 T ransactions, DB size = 150

Fig 6: T op 1/4 T ransactions, DB size = 100

53
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Simulation Results
0.04

0.25

0.2

Miss Ratio

0.03

Miss Ratio

Miss Ratio

Simulation Results

0.02

0.15

0.1

0.01
0.05

0
40

45

50

55

60

65

70

75

80

85

90

95

40

System Load (%)

PCP
DAP

BAP
ACP

T AP
RMS

Fig 8: T op 1/4 T ransactions, DB size = 200

45

50

55

60
65
70
75
System Load (%)

80

85

90

PCP
BAP
T AP
DAP
ACP
RMS
Fig 9: T he Whole T ransaction Set, DB siz = 100

54
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

95

Optimistic Concurrency Control

Broadcast Commit
Alternation of Serializability

55
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Real-Time Optimistic Concurrency Control

Example A - A simple optimistic CC

Three execution phases: read, validation, write.
Use timestamp to validate the serializability of trans.
Let the timestamp of A be before that of T.
Serializability consistency is not violated due to T if
A completed its write phase before T starts its read phase,or
The read set of A is distinct from the write set of T, and A
finished its write phase before T starts its write phase, or
The write set of A is distinct from both the read and write sets
of T.

Long transactions are been against because they tend

to have a lot of conflict.
56
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Real-Time Optimistic Concurrency Control

Variations:
Broadcast commit protocol:
When a transaction commits, it tells all the transactions that
it conflicts with so that they abort.

When priority is involved...

When T commits at its validation phase, all lower-priority
transactions abort.
Any higher priority transactions H in conflict with T...
Sacrifice policy - abort T.
Wait policy - Wait until H commits. If H commits, abort
T; otherwise, commit T.
Wait-X policy - T commits unless more than X% of the
transactions that conflict with it are of a higher priority;
otherwise, T waits (X=50 seems very good.)
57
@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Real-Time Optimistic Concurrency Control

Example B - Alternation of Serializability

Motivation: Reduce abortings by flexibly adjusting serializability order.
For example,
RA(x), RA(y), RA(z), RB(x), RA(u), WA(x), WB(v)
An acceptable order is B, A instead of A, B!!

An timestamp-based algorithm:
The system maintains a valid interval (x,y) for each transaction to assign the transaction a
timestamp at its commit time.
A read timestamp and a write timestamp for each data item which are the latest timestamps of
committed transactions that have read and updated it (updates done at commit times).
Updating of a data item at the commit time of a transaction is effective if the timestamp of the
transaction is larger than the write timestamp of the data item; otherwise, the write timestamp is
not changed and the update is simply ignored.

Example B.1:
x1(r=40,w=3), x2(r=2,w=60), timestamp(T1)=25, ReadSet(T1)= {x1}, WriteSet(T1)={x1,x2,x3}
After T1 commits, x1(r=40,w=25), x2(r=2,w=60), x1 is updated, x2 remains the same.
Remark: The serializability order of transactions scheduled by pessimistic CC is often determined at lock request times.

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

58

Real-Time Optimistic Concurrency Control

Example B.2: modifications of timestamp intervals
Time The write timestamp
25

33

T reads X

49

56

of each update.

Timestamp(T) must be in (33, 49)!

Time The read timestamp
63

85

90

potential commit point for T

of each read.

Timestamp(T) must be larger than 90!

Rules for assigning timestamps to a transaction T:

Determine the validity intervals of data read by T
Take the intersection of all these validity intervals. Let it be IT=(lT , uT). If the
interval is empty, then abort T.
Let maxT be the maximum read timestamp of all of the data items updated by T. If
maxT >= uT then abort T. Otherwise choose a timestamp for T in the interval
(maxT , uT).
59

Y. Lin and S.H. Son, Concurrency control in Real-Time Databases by Dynamically Adjustment of Serializability Order, IEEE Real-Time Systems Symposium, 1990, pp. 104-112.

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Real-Time Optimistic Concurrency Control

The protocol shown in Example B only considers the

transaction that is being validated in the context of the
transactions that have already been committed.
Validation Schemes1:(not exclusively classified)
Backward validation: The validation procedure is performed against recently
committed transactions.
Ti: validating transaction, Tj: transactions commit between the time Ti starts
execution and the time at which Ti comes to the validation phase.
Cond. 1: The writes of Tj should not affect the read phase of Ti.
Abort Ti if necessary.

Forward validation:The validation of a transaction is performed against

concurrently executing transactions.
Ti: validating transaction, Tj: transactions which currently executes in their
read phase.
Cond. 1: The writes of Ti should not affect the read phase of Tj.
Abort Ti or Tj depending on properties such as priority level.
60
@ all rights
preserved
forandTei-Wei
National
Taiwan
1. Kwok-Wa
Lam, Concurrency
Control
TransactionKuo,
Scheduling
in Real-Time
DatabaseUniversity
Systems, Ph.D. thesis, Dept. of Computer Science, City University of Hong Kong, 1997.

Real-Time Concurrency Control

Other papers for discussion

R. Abbott, H. Garcia-Molina, Scheduling Real-Time
Transactions: A Performance Evaluation,
Proceedings of the 14th VLDB Conference, 1988.
M.-C. Liang, T.-W. Kuo, and L.C. Shu,BAP: A Class
of Abort-Oriented Protocols Based on the Notion of
Compatibility, The Third International Workshop on
Real-Time Computing Systems and Applications, 1996.
T.-W. Kuo and A.K. Mok, SSP: a Semantics-Based
Protocol for Real-time Data access, IEEE 14th RealTime Systems Symposium, 1993.
61

@ all rights preserved for Tei-Wei Kuo, National Taiwan University

Introduction to Real-Time Database

Other Issues
Logging and Recovery
Query Optimization
Availability

62