Real-Time Database Systems and

Data Services: Issues and Challenges

Sang H. Son
Department of Computer Science
University of Virginia
Charlottesville, Virginia 22903
son@cs.virginia.edu

Outline
Introduction: real-time database systems and real-time data
services
Why real-time databases?
Misconceptions about real-time DBS
Paradigm comparison
Characteristics of data and transactions in real-time DBS
Origins of time constraints
Temporal consistency and data freshness
Time constraints of transactions
Real-time transaction processing
Priority assignment
Scheduling and concurrency control
Overload management and recovery

Outline (contd)
Advanced real-time applications
Active, object-oriented, main-memory databases
Flexible security paradigm for real-time databases
Embedded databases
Real-world applications and examples
Real-time database projects and research prototypes
BeeHive system
Research issues, trends, and challenges
Exercises

I. Introduction
Outline
Motivation: Why real-time databases and data services?
A brief review: real-time systems
Misconceptions about real-time DBS
Comparison of different paradigms:
Real-time systems vs real-time database system
Conventional DBS vs real-time DBS

Some Facts about Real-Time Databases

Fact 1: As the complexity of real-time systems and
application is going up, the amount of information to be
handled by real-time systems increases, motivating the
need for database and data service functionality (as
opposed to ad hoc techniques and internal data structures)
Fact 2: Conventional databases do not support timing and
temporal requirements, and their design objectives are not
appropriate for real-time applications
Fact 3: Tasks and transactions have both similarities and
distinct differences, i.e., traditional task centric view is not
plausible to real-time databases.

Something to Remember ...

Real-time FAST
Real-time nonosecs or secs
Real-time means explicit or implicit time constraints
A high-performance database which is simply fast without
the capability of specifying and enforcing time constraints
are not appropriate for real-time applications

A Brief Review: Real-Time Systems

A system whose basic specification and design
correctness arguments must include its ability to
meet its time constraints.
Its correctness depends not only on the logical
correctness, but also on the timeliness of its
actions.

Review: Real-Time Systems

Characteristics of real-time systems
timeliness and predictability
typically embedded in a large complex system
dependability (reliability) is crucial
explicit timing constraints (soft, firm, hard)
A large number of applications
aerospace and defense systems, nuclear systems,
robotics, process control, agile manufacturing, stock
exchange, network and traffic management,
multimedia computing, and medical systems
Rapid growth in research and development
workshops, conferences, journals, commercial products
standards (POSIX, RT-Java, RT-COBRA, )

Time Constraints
v(t)

Hard and firm deadline

v0

v(t)

Soft deadline

v0

d1

d2

10

Databases for Real-Time Systems

Critical in real-time systems (any computing needs
correct data)
real-time computing needs to access data:
real-world applications involve time constrained
access to data that may have temporal property
traditional real-time systems manage data in
application-dependent structures
as systems evolve, more complex applications require
efficient access to more data
Function of real-time databases
gathering data from the environment, processing it in
the context of information acquired in the past, for
providing timely and temporally correct response

11

What is a Real-Time Database?

A real-time database (RTDB) is a data store whose
operations execute with predictable response, and
with application-acceptable levels of logical and
temporal consistency of data, in addition to timely
execution of transactions with the ACID properties.
C. D. Locke
Chief Scientist, TimeSys Co.

12

Objectives of Real-Time Databases

Correctness requirements:
consistency constraints
time constraints on data and transactions
Objectives
timeliness and predictability:
dealing with time constraints and violations
Performance goals:
minimize the penalty resulting from actions either delayed or
not executed in time
maximize the value accruing to the system from actions
completed in time
support multiple guarantee levels of quality for mixed
workloads

16

Why Not Using Conventional Databases?

Inadequacies of conventional databases:
poor responsiveness and lack of predictability
no facility to support for applications to specify
and enforce time constraints
designed to provide good average response
time, while possibly yielding unacceptable
worst case execution time
resource management and concurrency control
in conventional database systems do not
support the timeliness and predictability
17

Differences from Traditional Databases

Traditional database systems
persistent data and consistency constraints
efficient access to data
transaction support: ACID properties
correct execution of transactions in the context of
concurrent execution and failure
designed to provide good average performance
Databases for real-time systems
temporal data, modeling a changing environment
response time requirements from external world
applications need temporally coherent view
actively pursue timeliness and predictability

18

Misconceptions on Real-Time Databases....

19

Misconceptions about RTDBS (1)

Advances in hardware till take care of RTDBS requirements.
fast (higher throughput) does not guarantee timing constraints
increase in size and complexity of databases and hardware will
make it more difficult to meet timing constraints or to show such
constraints will be met
hardware alone cannot ensure that transactions will be
scheduled properly to meet timing constraints or data is
temporally valid
transaction that uses obsolete data more quickly is still incorrect
Real-time computing is equivalent to fast computing.
minimizing average response time vs satisfying individual timing
constraints
predictability, not speed, is the foremost goal

20

Misconceptions about RTDBS (2)

Advances in standard DBS technology will take care of RTDB
requirements.
while novel techniques for query processing, buffering, and
commit protocols would help, they cannot guarantee timeliness
and temporal validity
time-cognizant protocols for concurrency control, commit
processing and transaction processing are mandatory
There is no need for RTDBS because we can solve all the
problems with current database systems
adding features such as validity intervals and transaction
deadlines to current database systems is in fact moving
towards to developing a real-time database system
such approach (adding features in ad hoc manner) will be less
efficient than developing one from the ground up with such
capabilities

21

Misconceptions about RTDBS (3)

Using a conventional DBS and placing the DB in main memory

is sufficient.
although main-memory resident database eliminate disk
delays, conventional databases have many sources of
unpredictability, such as delays due to blocking on locks and
transaction scheduling
increases in performance cannot completely make up for the
lack of time-cognizant protocols in conventional database
systems
A temporal database is a RTDB.
while both of temporal DB and RTDB support time-specific
data operations, they support different aspects of time
in RTDB, timely execution is of primary concern, while in
temporal DB, fairness, resource utilization, and ACID
properties of transactions are more important

22

Misconceptions about RTDBS (4)

Problems in RTDBS will be solved in other areas.
some techniques developed in other areas (e.g., RTS and DBS)
cannot be applied directly, due to the differences between
tasks and transactions, and differences in correctness
requirements
there are unique problems in RTDBS (e.g., maintaining temporal
consistency of data)
RTDBS guarantee is meaningless unless H/W and S/W never fails
true, in part, due to the complexity involved in predictable and
timely execution
it does not justify the designer not to reduce the odds of failure
in meeting critical timing constraints
Reference: Stankovic, Son, and Hansson, Misconceptions About RealTime Databases, IEEE Computer, June 1999.

23

Conventional vs. Real-Time Databases:

Correctness Criteria
Conventional Databases:
Logical consistency
ACID properties of
transactions:
Atomicity
Isolation
Consistency
Durability
Data integrity
constraints

Real-Time Database Systems:

Logical consistency
ACID properties (may be
relaxed)
Data integrity constraints
Enforce time constraints
Deadlines of transaction
External consistency
absolute validity interval
(AVI)
Temporal consistency
relative validity interval (RVI)

27

Real-time Systems vs. RTDBS

Real-time systems
Task centric
Deadlines attached to tasks
Real-time databases
Data centric
Data has temporal validity, i.e., deadlines also
attached to data
Transactions must be executed by deadline to
keep the data valid, in addition to produce
results in a timely manner

28

29

II. Characteristics of Data and Transactions

Outline
The origin of time constraints
Types of time constraints
Real-time data and temporal consistency
Real-time transactions

30

The Origin of Time Constraints

Meeting time constraints is of paramount importance in
real-time database systems. Unfortunately, many of these
time constraints are artifacts.
If a real-time database system attempts to satisfy them all,
it may lead to an over-constrained or over-designed system.

Issues to be discussed:
1. What are the origins of (the semantics of) time
constraints of the data, events, and actions?
2. Can we do better by knowing the origins of time
constraints?
3. What is the connection between time-constrained
events, data, and real-time transactions?

31

Example #1: Objects on Conveyor Belts

on a Factory Floor
Recognizing and directing objects moving along a set
of conveyer belts on a factory floor.
Objects features captured by a camera to
determine its characteristics.
Depending on the observed features, the object
is directed to the appropriate workcell.
System updates its database with information
about the object.
32

Example #1 (contd)
Features of an object must be collected while the
object is still in front of the camera.
Current object and features apply just to the object
in front of the camera
Lose validity once a different object enters the
system.
Objects features matched against models in
database.
Based on match, object directed to selected workcell.
Alternative: discard object and later bring it back
again in front of the camera.

33

Example #2: Air Traffic Control

System makes decisions concerning
incoming aircrafts flight path
the order in which they should land
separation between landings

Parameters: position, speed, remaining fuel, altitude,

type of aircrafts and current wind velocity.
Aircraft allowed to land => subsequent actions of this
aircraft become critical: cannot violate time
constraints
Alternative: Ask aircraft to assume a holding pattern.

34

Factors that Determine Time Constraints

Focus: externally-imposed temporal properties
The characteristics of the physical systems being monitored and
controlled:
speed of the aircraft, speed of conveyer belt, temperature
and pressure
The stability characteristics as governed by its control laws:
servo control loops of robot hands, fly-by-wire, avionics, fuel
injection rate
Quality of service requirements:
sampling rates for audio and video, accuracy requirement for
results
Human (re)action times, human sensory perception:
time between warning and reaction to warning
Events, data and actions inherit time constraints from these factors
They determine the semantics (importance, strictness) of time
constraints.

35

All Time Constraints are Artifacts?

May be not all of them, but even many externallyimposed constraints are artifacts:
Length of a runway or speed of an aircraft determined by cost and technology considerations;
Quality of service requirements - decided by
regulatory authorities;
Response times guaranteed by service providers determined by cost and competitiveness factors
36

Designer Artifacts
Subsequent decisions of the database system designer
introduce additional constraints:
The type of computing platform used (e.g. centralized vs.
distributed)
The type of software design methodology used (e.g., datacentric vs. action-centric)
The (pre-existing) subsystems used in composing the
system
The nature of the actions (e.g., monolithic action vs. graphstructured or triggered action)
Time constraints reflect the specific design strategy and the
subsystems chosen as much as the externally imposed
timing requirements

37

Decisions on Time Constraints

Difficulty of optimal time constraints
Determining all related time constraints in an
optimal fashion for non-trivial systems is
intractable => divide and conquer (and live with
acceptable decisions)
Multi-layer decision process
The decisions made at one level affect those at
the other level(s)
While no decision at any level is likely to be
unchangeable, cost and time considerations will
often prevent overhaul of prior decisions
38

Decisions on Time Constraints (2)

Decisions to be made
Whether an action is periodic, sporadic, or
aperiodic
The right values for the periods, deadlines, and
offsets within periods
Importance or criticality values
Flexibility (dynamic adaptability) of time
constraints

39

Time Constraints of Events

Three basic types of time constraints
1. Maximum: delay between two events
Example: Once an object enters the view of the camera,
object recognition must be completed within t1 seconds
2. Minimum: delay between two events
Example: No two flight landings must occur within t2 seconds
3. Durational: length of an event
Example: The aircraft must experience no turbulence for at
least t3 seconds before the seat-belt sign can be switched
off once again
Constraints can specify between stimulus and response events
(max, min, and duration between them can be stated)

40

Time Constraints of Events (2)

The maximum and minimum type of time constraints
of recurring (stimulus) events: rate-based constraints
Time constraints determine the constraints on
transactions:
Rate-based constraints -> periodicity
requirements for the corresponding actions
Time constraints relating a stimulus and its
response -> deadline constraints
Specifications of minimal separation between
response to a stimulus and the next stimulus ->
property of the sporadic activity that deals with that
stimulus

41

Data in Real-Time Database Systems

Data items reflect the state of the environment
Data from sensors - e.g., temperature and
pressure
Derived data - e.g., rate of reaction
Input to actuators - e.g., amount of chemicals,
coolant
Archival data - e.g., history of (interactions with)
environment
Static data as in conventional database systems

42

Time Constraints on Data

Where do they come from?
state of the world as perceived by the controlling
system must be consistent with the actual state
Requirements
timely monitoring of the environment
timely processing of sensed information
timely derivation of needed data
Temporal consistency of data
absolute consistency: freshness of data between
actual state and its representation
relative consistency: correlation among data
accessed by a transaction

43

Static Data and Real-Time Data

Static data
data in a typical database
values not becoming obsolete as time passes
Real-time (Temporal) data
arrive from continuously changing environment
represent the state at the time of sensing
has observed time and validity interval
users of temporal data need to see temporally
coherent views of the data (state of the world)
When must the data be temporally consistent?
ideally, at all times
in practice, only when they are used by transactions

45

An Example
Data object is specified by
(value, absolute validity interval, time-stamp)
Interested in {temperature and pressure}
with relative validity interval of 5
Let current time = 100
temperature = (347, 10, 95) and pressure = (50, 20, 98)
-- temporally consistent
temperature = (347, 10, 98) and pressure = (50, 20, 91)
-- temporally inconsistent

46

What Makes the Difference?

We have a set of predicates to be satisfied by data
Why not use standard integrity maintenance techniques?
Not executing a transaction will maintain logical
consistency, but temporal consistency will be violated
Satisfy logical consistency by CC techniques, such as 2PL
Satisfy temporal consistency by time-cognizant transaction
processing
AVI and RVI may change with system dynamics, e.g. mode
changes

47

Time Constraints Associated with Actions

Time constraints dictate the behavior of the environment
constrain the rates and times at which inputs arrive at
the system
Example: seek permission to land only when aircraft is
10 mins from airport
Time constraints prescribe performance of the system
dictate the responsiveness of the system to these inputs
Example: respond to a landing request within 30
seconds
Time constraints are imposed to maintain data temporal
consistency
Example: actions that update an aircrafts dynamic
parameters in 1 second

48

Distinct Types of Transactions

Write-only transactions (sensor updates): obtain state of
the environment and write into the database
store sensor data in database (e.g., temperature)
monitoring of environment
ensure absolute temporal consistency
Update transactions (application updates)
derive new data and store in database
based on sensor and other derived data
Read-only transactions
read data, compute, and report (or send to actuators)

49

Time Constraints on Transactions

Time constraints on transactions
some come from the need to maintain temporal
consistency of data
some come from the requirements on reaction time,
dictating the responsiveness of the system
some come from the designers choice, specifying the
rates and times at which inputs arrive at the system
transactions value depends on completion time

50

Types of Time Constraints

Based on type of time constraints:
Periodic
- Every 10 secs Sample wind velocity
- Every 20 secs Update robot position

Aperiodic
- If temperature > 1000
within 10 secs add coolant to reactor

Based on Value:
Hard: must execute before deadline
Firm: abort if not completed by deadline
Soft: diminished value if completed after deadline

51

Dealing with Time Constraint Violations

Large negative penalty => a safety-critical or hard time constraint
typically arise from external considerations
important to minimize the number of such constraints
No value after the deadline and no penalty accrues => a firm deadline
typically, alternatives exist
Result useful even after deadline => a soft deadline
system must reassign successors parameters - so that the overall
end-to-end time constraints are satisfied
Firm and soft time constraints offer the system flexibility - not present
with hard or safety-critical time constraints

52

Examples of Time Constraints Specified

using ECA (Event-Condition-Action) Rules
The time constraints can be specified using ECA rules
ON (10 seconds after initiating landing preparations)
IF (steps not completed)
DO (within 5 seconds abort landing)
ON (deadline of object recognition)
IF (action not completed)
DO (increase importance, adjust deadlines)
ON (n-th time violation within 10 secs)
IF (crisis-mode)
DO (drop all non-essential transactions)

53

Time Constraints: Discussion

Understand the issues underlying the origin and semantics
of time constraints
not all deadlines are given.
need ways to deriving time constraints (and semantics)
in the least stringent manner
flexibility afforded by derived deadlines must be
exploited
deadline violation must also be handled adaptively
Control strategies can be specified by ECA rules

54

55

III. Real-Time Transaction Processing

Outline

Priority assignment
Scheduling paradigms
Priority inversion problem
Concurrency control protocols
Predictability issues
Overload management and recovery

56

Priority Assignment
Different approaches
EDF: earliest deadline first
highest value (benefit) first
highest (value/computation time) first
complex function of deadline, value, slack time
Priority assignment has significant impact on database
system performance
Assignment based on deadline and value has shown
good performance

57

Goals of Real-Time Transaction Scheduling

Maximize the number of transactions (both sensor and
user) that meet deadlines
Keep data temporally valid
on overload, allow invalid intervals on data (note that
data with invalid interval may not be used during that
invalid time)
overload management by trading off quality for
timeliness and schedule contingency (or alternative)
versions of transactions
more on overload management later ...

59

Execution Time of Transactions

texec = tdb + tI/O + tint + tappl + tcomm
tdb = processing of DB operations

(variable)

tI/O

= I/O processing

(variable)

tint

= transaction interference

(variable)

tappl

= non-DB application processing (variable & optional)

tcomm

= communication time

(variable & optional)

60

Scheduling Paradigms
Scheduling analysis or feasibility checking of real-time
computations can predict whether timing constraints will
be met
Several scheduling paradigms emerge, depending on
whether a system performs schedulability analysis
if it does, whether it is done statically or dynamically,
and
whether the result of the analysis itself produces a
schedule or plan according to which computations are
dispatched at run-time

61

Different Paradigms
1. Static Table-Driven approaches:
Perform static schedulability analysis
The resulting schedule is used at run-time to decide
when a computation must begin execution
2. Static Priority Driven Preemptive Approaches:
Perform static schedulability analysis but unlike in the
previous approach, no explicit schedule is constructed
At run-time, computations are executed (typically)
highest-priority- first
Example: rate-monotonic priority assignment - priority is
assigned proportional to frequency

62

Different Paradigms (2)

3. Dynamic Planning Based Approaches:
Feasibility is checked at run-time, i.e. a dynamically arriving
computation is accepted for execution only if it found feasible
(that is, guaranteed to meet its time constraints)
One of the results of the feasibility analysis is a schedule or
plan that is used to decide when a computation can begin
execution.

4. Dynamic Best-effort Approaches:

No feasibility checking is done
The system tries to do its best to meet deadlines, but since no
guarantees are provides, a computation may be aborted
during its execution

63

Dealing with Hard Deadlines

All transactions have to meet the timing constraints

best-effort is not enough
a kind of guarantee is required
Requires
periodic transactions only
resource requirements known a priori
worst-case execution time of transactions are known
Use static table-driven or priority-driven approach
schedulability analysis is necessary
run-time support also necessary

64

Dealing with Soft/Firm Deadlines

Two critical functions:
assign transaction priorities
resolve inter-transaction conflicts using transaction
parameters: deadline, criticality, slack time, etc.
For firm deadlines, abort expired transactions
For soft deadlines, the transaction is continued to finish in
general, even if the deadline is missed
Various time-cognizant concurrency controls developed,
many of which are extensions of two-phase locking (2PL),
timestamp, and optimistic concurrency control protocols

65

Time-cognizant Transaction Scheduling

Earliest deadline first (EDF)
Highest value first
Highest value density first (value per unit computation time)
Weighted formula: complex function of deadline, value, and
remaining work, etc.
Earliest Data Deadline First: considering the validity interval
Example: DD(Y) is used as the virtual deadline of transaction T

Read X

Activate
TR T

Begin
TR T

Read Y

DD(Y)

DD(X)

Deadline
of TR T

66

Example 1 : Commit Case

Read X

Activate
TR T

Read Y

DD(Y)

Begin
TR T

DD = Data deadline

DD(X)

Deadline
of TR T
Commit
X and Y are valid
TR T makes deadline

67

Example 2 : Abort Case

Read X

Activate
TR T

Read Y

DD(Y)

Begin
TR T

DD(X)

Deadline
of TR T
ABORT

68

Example 3 : Forced Wait

DD(Y)

Read X

DD(X)

Read Y

Activate
TR T

Begin
TR T
Force TR T to Wait for Update to Y
since it will occur soon!

Deadline
of TR T

69

Example 4 : With Data Similarity

DD(Y) - Y updated to 15.78

Read X

Read Y
15.70
DD(X)

Activate
TR T

Begin
TR T

Deadline
of TR T
Commit
Deadline of TR T is met
Data X is OK
Data Y is similar (defined in DB)

70

71

Transactions: Concurrency Control

Pessimistic
Optimistic (OCC)
Hybrid (e.g., integrated real-time locking)
Speculative
Semantic-based
Priority ceiling

72

Pessimistic Concurrency Control

Locks are used to synchronize concurrent actions
Two-Phase Locking (2PL)
all locking operations precedes the first unlock
operation in the transaction
expanding phase (locks are acquired)
shrinking phase (locks are released)
suffers from deadlock
priority inversion

73

Example of 2PL: Two transactions

T1:

T2:
write_lock (X);
read_object (X);
X = X + 1;
write_object (X);
unlock (X);

Priority T1 > Priority of T2

read_lock (X);
read_object (X);
write_lock (Y);
unlock (X);
read_object (Y);
Y = X + Y;
write_object (Y);
unlock (Y);

74

Example of 2PL: Deadlock

T1:

T2:

read_lock (X);
read_object (X);
write_lock (Y); [blocked]
:

read_lock (Y);
read_object (Y);

write_lock (X); [blocked]

=> DEADLOCK !

:
:

75

Conflict Resolution in 2PL

2PL (or any other locking schemes) relies on blocking

requesting transaction if the data is already locked in an
incompatible mode. What if a high priority transaction needs a
lock held by a low priority transaction? Possibilities are ...
let the high priority transaction wait
abort the low priority transaction
let low priority transaction inherit the high priority and
continue execution
The first approach will result in a situation called priority
inversion
Several conflict resolution techniques are available, but the one
that use both deadline and value show better performance

76

Priority Inversion Problem in Locking

Protocols
What is priority inversion?
A low priority transaction forces a higher priority
transaction to wait
highly undesirable in real-time applications
unbounded delay may result due to chained blocking
and intermediate blocking:
Example: T0 is blocked by T3 for accessing data object,
then T3 is blocked by T2 (priority T0 > T2 > T3)

77

Example of 2PL: Priority Inversion

T 1:
Priority
inversion
write_lock (X); [blocked]
read_object (X);
X = X + 1;
write_object (X);
unlock (X);

T2:
read_lock (X);
read_object (X);
write_lock (Y);
unlock (X);

time

read_object (Y);
Y = X + Y;
write_object (Y);
unlock (Y);

78

Solutions to Priority Inversion Problem

Priority abort
abort the low priority transaction - no blocking at all
quick resolution, but wasted resources
Priority inheritance
execute the blocking transaction (low priority) with the
priority of the blocked transaction (high priority)
intermediate blocking is eliminated
Conditional priority inheritance
based on the estimated length of transaction
inherit the priority only if blocking one is close to
completion; abort it, otherwise

79

Conditional Priority Inheritance Protocol

Ti requests data object locked by Tj
if Priority (Ti) < Priority (Tj)
then block Ti
else
if (remaining portion of Tj > threshold)
abort Tj
else
Ti waits while Tj inherit the priority of Ti to
execute

80

Why Conditional Priority Inheritance?

Potential problems of (blind) priority inheritance:

life-long blocking - a transaction may hold a lock during
its entire execution (e.g., strict 2PL case)
a transaction with low priority may inherit the high
priority early in its execution and block all the other
transactions with priority higher that its original priority
especially severe if low priority transactions are long
Conditional priority inheritance is a trade-off between
priority inheritance and priority abort
Not sensitive to the accuracy of the estimation of the
transaction length

81

Performance Results
Priority inheritance does reduce blocking times. However, it
is inappropriate under strict 2PL due to life-time blocking of
the high priority transaction. It performs even worse than
simple waiting when data contention is high
Priority abort is sensitive to the level of data contention
Conditional priority inheritance is better than priority abort
when data contention becomes high
Blocking is a more serious problem than resource waste,
especially when deadlines are not tight
In general priority abort and conditional priority inheritance
are better than simple waiting and priority inheritance
Deadlock detection and restart policies appear to have little
impact

82

Optimistic Concurrency Control

No checking of data conflicts during transaction execution
read phase: read values from DB; updates made to local
copies
validation phase
backward validation or forward validation
conflict resolution

write phase:
if validation ok then local copies are written to the DB
otherwise discard updates and (re)start transaction

Non-blocking
Deadlock free
Several conflict resolution policies

83

OCC: Validation phase

If a transaction Ti should be serialized before a transaction
Tj, then two conditions must be satisfied:
Read/Write rule
Data items to be written by Ti should not have already
been read by Tj
Write/Write rule
Tis should not overwrite Tjs writes

84

OCC Example
T 1:
read_object (X);
X = X + 1;
write_object (X);
validation
<conflict resolution, .e.g, restart
transaction>

T2:
read_object (X);
read_object (Y);

T 3:
read_object (Y);
Y = Y + 1;
write_object (Y);
...

Y = X + Y;
write_object (Y);
validation
<conflict resolution, e.g.,
restart transaction>

85

OCC: Conflict Resolution

When a transaction T is ready to commit, any higherpriority conflicting transaction is included in the set H
Broadcasting commit (no priority consideration)
T always commits and all conflicting transactions are
aborted
With priority consideration: if H is non-empty, 3 choices
sacrifice policy: T is always aborted
wait policy: T waits until transactions in H commits; if
they do commit, T is aborted
wait-X policy: T commits unless more than X% of
conflicting transactions belong to H

86

OCC: Comparison
Broadcasting commit (no priority consideration)
not effective in real-time databases
Sacrifice policy: wasteful
theres no guarantee the a transaction in H will actually
commit; if all in H abort, T is aborted for nothing
Wait policy: address the above problem
if commit after waiting, it aborts lower priority
transactions after waiting, which may have not enough
time to restart and commit
the longer T stays, the higher the probability of conflicts
Wait-X policy: compromise between sacrifice and wait
X=O: sacrifice policy; X=100: wait policy
performance study shows X=50 gives the best results

87

Priority Ceiling Protocol

Why?
to provide blocking at most once property
the system can compute (pre-analyze) the worst case
blocking time of a transaction, and thus schedulability
analysis for a set of transaction is feasible
A complete knowledge of data and real-rime transactions
necessary: for each data object, all the transactions that
might access it need to be known
true in certain applications (hard real-time applications)
not applicable to other general applications

88

Priority Ceiling Protocol

For each data object O:
write-priority ceiling: the priority of the highest priority
transaction that may write O
absolute priority ceiling: the priority of the highest
priority transaction that may read or write O
r/w priority ceiling: dynamically determined priority
which equals absolute priority ceiling if O is write-locked;
equals write priority ceiling if O is read locked
Ceiling rule: transaction cannot lock a data object unless its
priority is higher that the current highest r/w priority ceiling
locked by other transactions
Inheritance rule: low priority transaction inherits the higher
priority from the ones it blocks
Good predictability but high overhead
89

90