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

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

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

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

More-Less Principle avi Pi

More-Less Principle

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

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

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

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

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

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

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

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

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)

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, 1-800 telephone service, ... WWW & e-commerce database Performance, reliability & availability can be significantly improved by replicating data on multiple sites

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

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

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

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