Motivation for real-time databases
Notions on Real-Time Databases
• The amount of information that is handled by real-time
systems increases, motivating the need for database
functionality
– As opposed to ad hoc techniques and internal data
structures
– Related fact: Development costs of RTS are very high!
Calin Curescu
• Fact 2: Conventional databases do not give real-time
guarantees.
Real-Time Systems Laboratory
Department of Computer and Information Science
Linköping University, Sweden
• Fact 3: Tasks and transactions have both similarities and
distinct
The lecture notes are partly based on lecture notes by Jörgen Hansson, and Thomas Gustafsson. These
lecture notes should only be used for internal teaching purposes at Linköping University.
Notions on Real-Time Databases
Calin Curescu
26 pages
TDDB47, 2006
Notions on Real-Time Databases
Calin Curescu
Sources of unpredictability
2 of 26
TDDB47, 2006
Real-time system
• Database Systems:
– Dynamic paging and I/O
– Data and resource conflicts
– Transaction aborts
• rollbacks/restarts
– Transaction execution time
• Distributed Databases:
– Network communication
– Distributed commit processing
• Distributed rollbacks/restarts
– Site failures
Notions on Real-Time Databases
Calin Curescu
3 of 26
TDDB47, 2006
Notions on Real-Time Databases
Calin Curescu
RTS+RTDB
4 of 26
TDDB47, 2006
What’s a real-time database?
• A real-time database (RTDB) ensures
– predictable response, and
– application-acceptable levels of
• External consistency
• Temporal consistency
• Logical consistency
• Atomicity
• Permanence
• A database system facilitate description of data
maintenance of correctness and integrity of data efficient
access to data correctness of transaction execution.
Notions on Real-Time Databases
Calin Curescu
5 of 26
TDDB47, 2006
Notions on Real-Time Databases
Calin Curescu
6 of 26
TDDB47, 2006
Applicaitions
Example: Engine Control Unit
•
•
•
•
Air Traffic control
Command Control Systems
Manufacturing Plant
Navigation and Positioning Systems
– Automobiles, airplanes, etc.
• Network Management Systems
• Telecommunication
– Mobile phones, etc.
• Training Simulation System
– Pilot training, etc.
Notions on Real-Time Databases
Calin Curescu
7 of 26
TDDB47, 2006
ACID Properties
Notions on Real-Time Databases
Calin Curescu
Temporal constraint on transactions
• Atomicity
– An atomic transaction is a database transaction which either
completely occurs (commits), or has no effects (rolled back).
• Consistency
– A consistent transaction is one that does not violate any
integrity constraints during its execution.
• Isolation
– The changes made by a transaction are not visible to other
simultaneous transactions on the system until its completion.
• Durability
– Transactions that are successfully committed will survive
permanently and will not be undone by system failure.
• Execution Time of Transactions
– texec= tdb + tI/O + tint + tappl + tcomm
Notions on Real-Time Databases
Calin Curescu
Notions on Real-Time Databases
Calin Curescu
9 of 26
TDDB47, 2006
8 of 26
TDDB47, 2006
– tdb = processing of DB operations
– tI/O = I/O processing
– tint = transaction interference
• data conflicts, transaction restarts
– tappl = non-DB application processing - optional
– tcomm = communication time - optional
Temporal Constraints on Data
10 of 26
TDDB47, 2006
AVI
• External consistency
– State of environment and reflection in DB
– Absolute Validity Intervals (AVI)
– d : (value, avi, ts)
• ts = time of observation
– (current_time - ts) ≤ avi
• Temporal consistency
– Among data used to derive other data
– Relative Validity Intervals (RVI)
– ∀d’ ∈ R , |ts - ts’| ≤ rvi
– d ∈R, R – relative consistency set
Notions on Real-Time Databases
Calin Curescu
11 of 26
TDDB47, 2006
Notions on Real-Time Databases
Calin Curescu
12 of 26
TDDB47, 2006
RVI
Tasks vs. transactions
• Tasks
– Are generally designed to be nonterminating cooperative
– Critical regions / rendez-vouz – i.e. not serializable
– Wait primarily/only for other tasks
– Run-time behavior statically predictable
• Transactions
– Are always designed to terminate
– Require isolation in order to ensure consistency – i.e. serialisable
– Wait for completion of I/O events (and possibly other data
objects)
– Dynamic run-time behavior depends on data values etc.
Notions on Real-Time Databases
Calin Curescu
13 of 26
TDDB47, 2006
Tasks vs. transactions
• Tasks
– Resources accessed by more than one task in a RTS are few
in number
– Resources are generally known at design time.
• Transactions
– Number of resources (data objects) is very large
– Resources not known at design time
– Usually the database is normally much larger than its active,
in-use subset, at any moment.
– Very low probability of conflict between transactions.
• Potential conflict is high
• Actual conflict is low
Notions on Real-Time Databases
Calin Curescu
15 of 26
TDDB47, 2006
Notions on Real-Time Databases
Calin Curescu
Conventional vs. rt correctness criteria
• Conventional DBS
– Logical consistency
– ACID properties
• Real-Time DBS
– Logical consistency
– ACID properties (may be relaxed)
– Enforce time constraints
• Transactions
– External consistency
• Absolute validity interval (AVI)
– Temporal consistency
• Relative validity interval (RVI)
Notions on Real-Time Databases
Calin Curescu
Distinct types of transactions
• Write-only transactions
– Store sensor data in DB
• e.g. temperature
– Monitoring of environment
– Ensure external consistency
14 of 26
TDDB47, 2006
16 of 26
TDDB47, 2006
Update transactions
• Triggering of transactions to refresh data items
– Refresh data items before they are used
• Triggering criterion
• On-demand updating can be either
– Consistency-centric, or
– Throughput-centric
• Update transactions
– Derive new data and store in DB
– Based on sensor data
• Read-only transactions
– Forward data to actuators
Notions on Real-Time Databases
Calin Curescu
17 of 26
TDDB47, 2006
Notions on Real-Time Databases
Calin Curescu
18 of 26
TDDB47, 2006
Transactions: concurrency control
Pessimistic concurrency control
• Optimistic (OCC)
• Locks the data it wants to use
• Pessimistic (PCC)
• 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)
• Speculative
• Exploit data similarity
• Allows deadlock
• Allows priority inversion
Notions on Real-Time Databases
Calin Curescu
19 of 26
TDDB47, 2006
Notions on Real-Time Databases
Calin Curescu
2PL priority inversion
Notions on Real-Time Databases
Calin Curescu
21 of 26
TDDB47, 2006
Possible strategies
20 of 26
TDDB47, 2006
2PL deadlock
Notions on Real-Time Databases
Calin Curescu
22 of 26
TDDB47, 2006
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
• May need conflict resolution
Notions on Real-Time Databases
Calin Curescu
23 of 26
TDDB47, 2006
Notions on Real-Time Databases
Calin Curescu
24 of 26
TDDB47, 2006
OCC: validation phase
OCC example
• If a transaction Ti should be serialised 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
Notions on Real-Time Databases
Calin Curescu
25 of 26
TDDB47, 2006
Notions on Real-Time Databases
Calin Curescu
26 of 26
TDDB47, 2006