1. Real-Time Databases and Data Services
Krithi Ramamritham, Sang Son, Lissa Dipippo

2. Outline Timing & Data Freshness Requirements
Transaction Processing in RTDB
QoS & QoD
New Applications: Sensor networks, Mobile RTDB, Web
Research challenges

3. Data Freshness Reminder: Half-half principle
Update period Pi for data Xi = 0.5 avi(Xi)
Guarantee freshness
Double the utilization

4. More-Less Principle
Minimize the CPU utilization of sensor transactions, while guaranteeing freshness
Period Pi > 0.5avi(Xi): Decrease utilization
Relaitve deadline Di < 0.5avi
Pi + Di = avi(Xi)
Farthest distance btwn two consecutive updates is Pi + Di
Freshness is gauranteed if the deadline is met
Prictorial explanation next

5. More-Less Principle
avi Pi

6. More-Less Principle

7. But More-Less is not panecea
Deadline is decreased as period increases
More stringent timing constraints on sensor transactions
Deadline Monotonic Scheduling should be used to schedule sensor transactions
Dynamic priority scheuling cannot be used
Refer to Ming Xiong’s RTSS ’05 paper for dynamic priority update scheduling

8. Scheduling & Concurrency Control
Dealing with hard deadlines
Sha et al. (1988) – periodic trasnsactions with known WCETs under RMS
Period & WCET of a transaction shoud be known a priori
Restrictions on transactions
Difference btwn average caase exec time and WCET should be small; otherwise, poor resource utilization

9. Scheduling & Concurrency Control: Dealing with Soft Deadlines
EDF
Highest value first
Highest value density (value/exec time) first
Longest-executed transaction first

10. Concurrency Control 2PL variations
Priority abort (called 2PL-PA or 2PL-HP)
Immediately a lower priority transactoin upon a data conflict
Performance varies depending on data contention
Priority inheritance
A low priority transaction blocking a high priority inherits the high priority
Hybrid
A low priority transaction close to finishing inherits the priority

11. Optimistic Concurrency Control
An ongoing transaction optimistically assumes there’s no data contetion. After fishing all its read/write operations, it enters the validation stage to see whether or not it can commit
Backward validation: A validating transaction either commits or aborts depending on whether it has conflicts with already committed transactions
It does not allow to consider transaction characteristics for conflict resolution

12. Optimistic Concurrency Control
Forward validation: A validating transaction aborts transactions conflicting with itself
Wait-50: A validating transaction has to wait if more than 50% of the transactions that conflict with it have earlier deadlines; otherwise, it commits aborting the conflicting, on-going transactions

13. Optimistic Concurrency Control
Timestamp orderging
Multiversion CC
Reduce data conflicts by allowing to read one version, while updating another version
Absolute & relative consistence management can be more complicated if temporal consistency should be supported

14. Data deadlines Data dealine Earliest Data Deadline First Forced Wait
Deadline assigned to a transaction due to data temporal consistency
Transaction Ti’s deadline is time 10, but it has to read a data which becomes stale at time 7 -> Make Ti’s deadline be 7
Earliest Data Deadline First
Forced Wait
Delay further execution until a new version of sensor data becomes available

15. Data similarity
Use old but similar data without affecting the result (within the specified bound)
Similarity Stack Protocl: Kuo & Mok (1993)
Weaker consistency requirement based on similarity concept: Kuo & Mok (2000)
Combined with data deadline: Xiong et al. (2002b)

16. Distributed Databases & Commit Protocols
Many RTDB applications are distributed, but little work has been done for distributed RTDB
Intelligenet network service database, telecom database, mobile telecommunication systems, telephone service, ...
WWW & e-commerce database
Performance, reliability & availability can be significantly improved by replicating data on multiple sites

17. Distributed Databases & Commit Protocols
Multiversion technique in DRTDB: Son (1987)
MIRROR: Xiong et al (2002b)
Relax one-copy serializability
Temporal consistency guarantees between primary and backup copies in distributed environment
Distance-constrained scheduling

18. Distributed Databases & Commit Protocols
Two-Phase Commit (2PC) protocol
Voting phase: Each node votes whether or not a transaction can commit
Commit phase: Commit if unanimous; otherwise, abort
Expensive
Make it real-time?
Enter the 2nd phase, i.e., the commit phase, only if the vote is unamious and the transaction can commit within its deadline

19. Distributed Databases & Commit Protocols
PROPMT: Haristsa et al. (2000)
Allow transactions to borrow data updated by the transactions in their commit phase to reduce data inavailability & priority inversion

20. Satisfying QoS/QoD requirements
To be discussed in the next class...