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
1
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
2
Outline (cont’d)
 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
3
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
4
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 realtime databases.
5
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
7
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.
8
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, …)
9
Time Constraints
v(t)
Hard and firm deadline
v0
d
t
v(t)
Soft deadline
v0
d1
d2
t
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 applicationdependent 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 applicationacceptable 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 realtime 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 (cont’d)
 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.
 Object’s 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 externally-imposed
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 aircraft’s 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 designer’s choice, specifying the rates
and times at which inputs arrive at the system
 transaction’s 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 runtime
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) highestpriority- 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
Deadline
of TR T
Force TR T to Wait for Update to Y
since it will occur soon!
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
T 1:
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
T1:
Priority
inversion
write_lock (X); [blocked]
read_object (X);
X = X + 1;
write_object (X);
unlock (X);
T 2:
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
 Ti’s should not overwrite Tj’s writes
84
OCC Example
T1 :
T 2:
read_object (X);
X = X + 1;
write_object (X);
validation
<conflict resolution, .e.g, restart
transaction>
read_object (X);
read_object (Y);
T3 :
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 higher-priority
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
 there’s 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