RealTime Databases

1
Real-Time Databases
2
Basic Definitions

• ACID properties of a transaction
• Atomicity The end result of running transactions
  must be the same as when each transaction is an
  atomic action. An action is said to be atomic if
  it is either done completely or not at all.
• Consistency The transaction transforms the
  database from consistent state to another. A
  consistent state is one that results from the
  execution of some given sequence of transactions.
• Isolation The actions of a transaction are not
  visible to any other transactions until and
  unless that transaction has committed.
• Durability The actions of a transaction on a
  database (upon commitment) are permanent.
• Two operations conflict with one another if
  they relate to the same
• data item and at least one of them is write.

3

• A given history S is serial if only one
  transaction is active
• at any one time.
• Example S has transactions T1, T2, and T3
• transaction T1 starts at time 0 and completes
  at time 5
• transaction T2 starts at time 10 and
  completes at time 29
• transaction T3 starts at time 40 and
  completes at time 55
• A history S is said to be finite-state
  serializable or to
• maintain finite-state serialization
  consistency if the net
• effect of the operations is as if the
  transactions were
• executed in some serial order.
• Example
• The history R1(x)W1(x)R2(x)W2(x)R1(y)R2(y) is
  finite-
• state serializable
• ?we first executed transaction T1 to
  completion,
• and then began transaction T2
• R1(x)R2(x)W1(x)W2(x) is not serializable

4
Real-Time vs. General-Purpose Databases

• Real-time databases
• Queries to the database have deadlines associated
  with them.
• either hard or soft
• The data returned in response to a query must
  have both absolute consistency and relative
  consistency.
• Absolute vs. Relative Consistency
• Absolute consistency is accuracy i.e., data
  about the operating environment must be
  consistent with the environment.
• Relative consistency for multiple data, the data
  must have been collected reasonably close to one
  another.

5

• Example
• to obtain a composite picture of the
  pressure and the temperature of a boiler, the
  temperature and pressure should be taken within a
  short time each other.
• Time Temperature Pressure
• 100 100 360
• 200 300 720
• 300 700 100
• if our database query returns values of
• 100 for the temperature (measured at time 100)
  and
• 100 for the pressure (measured at time 300)
• ? the composite temperature-pressure picture
  is inconsistency

6

• Example
• Associate with each datum a consistent
  interval, over
• which it is absolutely consistent
• Associate with each pair of data (x , y) a
  computability or relative consistency interval
  c(x , y) of duration tc(x , y).
• Denote by tx , ty the timestamps on data (x , y)
• Define vx , vy so that
• x is absolutely consistent over the interval
  tx , tx vx
• y is absolutely consistent over the interval
  ty , ty vy
• The pair (x , y) is only consistent at time t if
  tx - ty ? tc(x , y)
• and if both x and y are absolutely consistent
  at that time ( i.e.,
• t - tx ? vx and t - ty ? vy
• vx , vy and c(x, y) could vary with time.
• Relative consistency is defined w.r.t. a set of
  data
• Absolute consistency is defined w.r.t. an
  individual data

7

• Example the timestamps of x and y are 0 and 1.75
  respectively.
• assume that tc(x , y)
  1.5
• In the left figure x, y have absolute
  consistency in the interval
• Ax 0.00, 2.00, and Ay 1.75, 2.75
  respectively.
• ? over the interval AxnAy 1.75, 2.00 ? both
  absolutely consistent
• the pair (x, y) is not relatively consistent
  anywhere ? the timestamps
• of x and y differ by more than tc(x , y)
• In the right figure x, y have absolute
  consistency in the interval
• Ax 0.00, 2.00, and Ay 1.00, 2.00
  
• and the pair (x, y) is relatively consistent
  over the interval
• Rx,y 1.00, 1.50
• __y__
  __y _
• ___ x _____
  ___ x _____
• _______________
  _______________
• 0 1 2 3
  0 1 2 3

8

• Need for Response-Time Predictability
• Transactions may be aborted one or more times
  before they are finally completed ? delay the
  affected transaction.
• Rely on disk systems ? page faults may occur
• Transaction accesses (R/W) may be data-dependent
• Transactions may suffer a delay because they are
  waiting to access a datum that is currently
  locked by another transaction.
• ?We must make worst-case assumptions to guarantee
  that critical hard deadlines will continue to be
  met.
• ?How long the transaction will take to run in the
  absence of conflicts with other transactions?

9

• Relaxing the ACID Properties
• In some applications, it may not be necessary to
  ensure that all the ACID properties are met.
• In some cases, it might be possible to sacrifice
  serialization consistency.
• If we are willing to relax serialization
  consistency, we must provide some means for
  recovery when one of the interleaved transactions
  is aborted.

10

• Example an airline reservation database
• Hartford(HFD) ? Chicago(ORD) ?Detroit(DTW)
• Reservation
• Reserve a seat on a flight from Hartford to
  Chicago
• If over 100 seats sold, assign 5 flight
  attendants to the flight
• otherwise assign 3 attendants
• 2. Reserve a seat on a flight from Chicago to
  Detroit
• If over 100 seats sold, assign 5 flight
  attendants to the flight
• otherwise assign 3 attendants
• Cancellation
• 1. Release a seat on a flight from Hartford to
  Chicago
• If the number of reservation drops below
  85,
• assign only 3 flight attendants to this
  flight.
• 2. Release a seat on a flight from Chicago to
  Detroit
• If the number of reservation drops below
  85,
• assign only 3 flight attendants to this
  flight.

11

• Serialization consistency would be violated if
  the
• reservation and cancellation transactions
  were interleaved.
• Example
• -- we have sold 99 seats on both the HFD ?ORD
• and ORD ? DTW
• -- 3 flight attendants are concurrently
  allocated to each flight
• Case 1 Reserve first ? 99 reservations on both
  flights but 5 flight
• attendants are assigned to them
• Case 2 Cancellation first ?99 reservations on
  both flights and 3 flight
• attendants are assigned to them
• Case 3 relaxing serialization consistency
• R(HFD,ORD)?C(HFD,ORD) ?C(ORD,DTW)?R(ORD,DTW)
  
• ? 99 reservations on both flights
• but 5 flight attendants are assigned
  to the HFD?ORD flight,
• and 3 to the ORD?DTW flight.

12
Main Memory Database

• If the real-time database is sufficiently
  small?practical
• The lower the response time, the lower the
  probability of lock contention.
• Contention will increase both the granule size
  and the transaction duration
• Reducing the transaction duration ? be able to
  increase the granule size without adversely
  affecting the concurrency that the system can
  support.
• Main memory database organization
• ? using pointers, indexing, T-tree ( binary
  tree with multiple
• elements per nodes)
• Backups will be relatively more expensive
  (relative to transaction time) in main memory
  databases than in disk-based databases.

13

• Transaction Priorities
• To ensure that some system measure of performance
  is optimized the fraction of transactions that
  do not meet their deadlines
• Depending on application
• To discard transactions that have missed their
  deadline
• Continue to serve all transactions (whether or
  not they are late)
• missed deadlines ? be kept in background
• have not missed deadlines ?be scheduled using the
  EDF algorithm
• AED (Adaptive earliest Deadline) algorithm
• combines congestion control with the EDF
  algorithm

14

• AED algorithm
• The arrived transaction is randomly inserted in a
  list of pending transactions
• If its assigned position is in the list 1..H ?
  assigned to the HIT group,
• the remaining ones are assigned to the MISS
  group
• Transactions within the HIT group ? EDF algorithm
• Transactions within the MISS group ? served ( in
  the order of their positions in the list) if no
  pending transactions exist in the HIT group ? no
  dependencies among the transactions, and the
  ordering among them is irrelevant.

15

• H 0 ? random service scheme H 8 ? EDF
• transactions in
  HIT class that meet their deadlines
• Success(HIT) ----------------------------------
  --------------------------------
• Total number of
  transactions in the HIT class
• Total number of
  transactions that meet their deadlines
• Success(ALL) ----------------------------------
  --------------------------------
• Total
  number of transactions
• H Success(HIT) H 1.05
• If success(ALL) lt 0.95, then
• H min H, Success(ALL) N_trans
  1.25
• ? Load is low enough, almost all the
  transactions can be placed in the HIT class
• Load increases to the point where Success(ALL) lt
  0.95, H is revised downward

16

• Transaction Aborts
• Termination abort is not restart after being
  aborted
• Non-termination abort it is restarted, because
  of
• ?data conflicts with another
  higher-priority transaction
• ?the transaction may have been delayed for
  so long that
• its value has declined to zero.

17

• Concurrency Control Issues
• Pessimistic concurrency control first ensure
  that the transaction will not violate
  serialization consistency before letting it
  execute.
• Optimistic first carry out the transaction
  execution, and only then check to see if the
  execution of that transaction has violate
  serialization consistency.

18

• Pessimistic Concurrent Control
• Two-phase locking ( in centralized database)
• -- In the locking phase it acquires the read and
  write locks it needs
• -- In the unlocking phase it releases the locks,
  must follow (and not overlap) the locking phase.
• The transaction must have obtained all the locks
  it will need before it releases any locks
• has potential to deadlock
• -- running deadlock detection algorithm,
  abort a transaction
• Modified two-phase locking for use in Real-time
  system
• -- priority inversion problem ? inherit the
  priority
• works well in general-purpose real-time
  applications, is not as useful in real-time
  databases ( tends to require much more time to
  complete)
• ? to abort the lower-priority transaction
• ? how close the lower-priority transaction
  is to finishing
• threshold-based algorithm

19

• Threshold-based algorithm
• If the lower-priority task is sufficient close to
  completion
• ? let it inherit the priority of the
  higher-priority task and make the higher-priority
  task wait until it finishes.
• If not, the lower-priority task is aborted, and
  the higher-priority task can start right away
• ? The time for which the higher-priority task is
  blocked is bounded by the threshold.
• To make the threshold a function of the
  difference in priority levels between the
  higher-priority and lower-priority transactions
• The greater the difference, the smaller the value
  of the threshold
• How to choose the threshold
• to use an adaptive learning procedure and let the
  system modify the threshold until it reaches a
  good value.
• To use multiple versions of data

20

• Locking rules for a general multi-version
  database system
• Read, write, and certify locks
• When a transaction writes a data item
• writes into its private copy (does not locks the
  database copy)
• A transaction can obtain a write lock without
  interfering with any other transactions ( write
  lock on a granule will not be exclusive)
• When the transaction has completed execution ? it
  copies all of its writes over to the database ?
  Certification
• The transaction must receive a certify lock on
  the data item(s) being certified before this
  stage can go ahead
• The transactions are limited to reading the
  latest certified version of data. ? ensures that
  cascading aborts are avoided.
• 
  Requested lock
• Locks already set Read Write
  Certify
• Read Granted
  Granted Blocked
• Write Granted
  Granted Granted
• Certify Blocked
  Granted Blocked

21

• Locking rules to deal with priority inversion
  problems
• Locks already set Lock requested by a
  HPT
• By the LPT Read
  Write Certify
• Read Granted
  L-aborted Cannot occur
• Write Granted
  Granted Granted
• Certify Conversion
  Granted Conversion
• --------------------------------------------------
  ------------------------------
• Locks already set Lock requested
  by a LPT
• By the HPT Read
  Write Certify
• Read Granted
  Granted Blocked
• Write Blocked Granted
  Blocked
• Certify Blocked
  Granted Blocked
• Note Conversion LPT lock converted to Write
• ?avoid the priority inversion problem
• ?may cause the LPT to abort in a large number of
  cases

22

• Modified locking rules to reduce abortions
• Locks already set Lock requested by a
  HPT
• By the LPT Read
  Write Certify
• Read Granted
  Granted L-aborted
• Write G/B
  Granted Granted
• Certify Blocked
  Granted Conversion
• --------------------------------------------------
  ------------------------------
• Locks already set Lock requested
  by a LPT
• By the HPT Read
  Write Certify
• Read Granted
  Granted Blocked
• Write Blocked
  Granted G/B
• Certify Blocked
  Granted Blocked
• Note G/B Either granted or blocked, depending
  on
• implementation

23

• Optimistic Concurrent Control
• Three phases read, validation, and write phases
• Read phase the transaction reads data it needs,
  and writes only into its own private address
  space
• Validation phase the system checks to see if any
  of the writes has potentially violated
  serialization consistency
• For every transaction A whose timestamp antedates
  that of transaction T, serialization consistency
  is not violated due to T if
• A has completed its write phase before T starts
  its read phase
• The read set of A is distinct from the write set
  of T, and A has finished its write phase before T
  starts its write phase
• The write set of A is distinct from both the read
  and write sets of T.
• ? If these conditions are not satisfied, T must
  be aborted.

24

• Optimistic Concurrent Control (cont.)
• The longer a transaction, the greater the
  probability that it will be aborted before it
  reaches its commit point.
• The probability of a transaction being aborted is
  roughly proportional to the square of its length
  and to system load.
• This system discriminates heavily against long
  transactions, and this discrimination gets worse
  as the system load increases.

25

• The Basic Optimistic algorithm
• The broadcast commit algorithm.
• When a transaction commits, it tells all the
  transactions that it conflicts with so that they
  abort (and then possibly restart)
• with priority
• When a transaction T is about to commit, any
  lower-priority transactions that conflict with it
  are aborted.
• The system checks to see if any higher-priority
  transactions currently in the system conflicts
  with T.

26

• H is the conflict set.
• If H is nonempty, one of the following actions
  is taken.
• The sacrifice policy T is aborted ( it can be
  restarted)
• The wait policy T is put into a wait state until
  the tasks in H commit. If they do, T is aborted
  (can be restarted).
• The wait-X policy T commits unless more than X
  of the transactions that conflict with it are of
  higher priority ( i.e.,belong to H).
• ? all the transactions it conflict with
  are aborted.
• If more than X are of higher
  priority, it waits for
• them to commit.

27

• Maintaining Serialization Consistency
• Serialization consistency without alteration of
  serialization order
• The system assigns a particular order to
  the transactions and aborts any that do not
  maintain serialization consistency as defined by
  that order.
• Serialization consistency with alteration of
  serialization order
• It is possible to reduce the number of
  transaction abortions by suitable adjusting
  serialization order.

28

• Serialization consistency without alteration of
  serialization order
• serialization order can be defined based on
  
• Start time if transaction A has an earlier start
  time than transaction B, then it must occur
  before B in the serialization order.
• Completion time if transaction A has an earlier
  completion time than transaction B, then A
  precedes B in the serialization order followed
  by the classical optimistic concurrency control
  algorithm.
• Item access order if transaction A conflicts
  with B on some data item x, then whichever one, A
  or B, that accesses x first will come first in
  the serialization order.
• Any inconsistencies must be dealt with by
  aborting transactions
• suitably.

29

• Serialization consistency with alteration of
  serialization order
• Example consider the sequence of
  operations
• S RA(x), RA(y), RA(z), RB(x), RA(u),
  WA(x), WB(v)
• If we serialize by start order, then B is deemed
  to follow A
• ? B to be aborted.
• A similar characterization applies to
  serialization by completion order.
• If we have B preceding A with the order, the
  sequence is serializable and so neither
  transaction is aborted.
• ? assigning timestamps to committing
  transactions in such a way that if the timestamp
  of transaction A, t(A) precedes that of
  transaction B, t(B), then the database state is
  the same as it would be if A were run before B in
  a sequential processing system.

30

• When a transaction T reads x commits, the read
  timestamp of x is set to the maximum of its
  current read timestamp and the timestamp of
  transaction T.
• If T updates x, then the following rule is
  applied.
• If the current write timestamp of x is less than
  the timestamp assigned to T, the update is
  written into the database, and the write
  timestamp of x is made equal to the timestamp of
  T.
• If, on the other hand, the current write
  timestamp of x is greater than the timestamp of
  T, the update is not written into the database.
• The system maintains a historical list of all
  read and write timestamps of each data granule.

31

• Example
• Transaction T is assigned a timestamp 25
  when it commits. Read set x1, x2, x3 write
  set x3, x4
• variable
  variable
• x1 x2 x3 x4
  x1 x2 x3 x4
• Read timestamp 4 4 40 2 ?
  25 25 40 2
• Write timestamp 1 2 3 60
  1 2 25 60
• (when T
  commits)
• x3 is updated in the database, but x4 is not (
  since the
• database already has a version written by a
  transaction
• with timestamp 60.

32

• To assign timestamps to transactions so that
  serialization consistency is maintained.
• Start by trying to timestamp the transaction with
  the current time (i.e., the time told by
  real-time clock) or by the time at which it was
  released.
• Check to see if consistency is maintained
• yes the transaction can be committed with
  that
• timestamp
• no we must try to adjust the timestamp
  to that
• serialization consistency is not
  violated.

33

• Example
• a variable x that is read (but not updated) by
  transaction T.
• ______________________________________________
• 25 33 T reads x 49
  56 73 ? write
• 
  
  timestamps
• Updates of variable x
• -- What constraints does this impose on the
  timestamp t(T) that we can
• assign to T ?
• 1. if t(T) lt 33, the fact that T reads an
  update timestamped 33, violates serialization
  consistency
• 2. If t(T) gt 49, is also not allowed. ( T
  would be reading an overwritten value of x)
• 3. If we assign t(T) in (33,49), this will
  meet consistency constraints.
  

34

• Example
• a variable y that is updated by transaction
  T.
• __________________________________________
• 
  
• 18 44 63
  85 90
• read timestamps
• 
  potential commit
• 
  point
  for T
• -- Reads of variable y when y is read and the
  read timestamps
• associates with each read.
• -- The update made by T will not have been seen
  by any of the
• transactions that already read y (since T
  has not committed yet).
• ? we must have t(T) gt 90
• ? have the conflicting requirements that 33 lt
  t(T) lt 49 and t(T) gt 90
• ? there is no way to assign timestamps to T to
  maintain serialization consistency
• ? T must be aborted.

35

• Example
• a variable y that is updated by transaction
  T.
• __________________________________________
• 
  
• 18 24 33
  40 45
• read timestamps
• 
  potential commit
• 
  point
  for T
• -- Reads of variable y, 2nd case the latest
  committed transaction that reads y is
• timestamped 45
• -- Setting t(T) gt 45 will meet the serialization
  consistency requirement
• Constraints due to x and y will both be met if
  we set 45 lt t(T) lt 49, and serial consistency can
  be preserved.

36

• The rules for assigning timestamps to a
  transaction T
• List the set of variables that the transaction
  read.
• Determine the validity intervals of these data
  (i.e., the range of timestamps over which these
  data are valid). For example, in the above
  figure, the value of x as read by T has a
  validity interval of (33,49)
• Take the intersection of all these validity
  intervals. If this intersection is empty, then
  abort T. If the intersection time is nonempty,
  let it be IT (lT, uT)
• Now list all the variables that T has updated.
• Let maxT be the maximum read timestamp of all of
  these variables. If maxT ? uT, then abort T.
  Otherwise, choose a timestamp in the interval
  (maxT, uT), and commit T.