Advanced Database System

1
Advanced Database System

• CS 641
• Lecture 19

2
Other mechanisms

• Timestamping
• Validation

3
Comparison

• Timestamping and validations are optimistic that
  they assume that no unserializable behavior will
  occur and only fix things up when a violation is
  apparent.
• Locking methods assume that things will go wrong
  unless transactions are prevented in advance from
  engaging in nonserializable behavior.

4
Comparison (Cont.)

• In optimistic approaches , the only remedy when
  something does go wrong is to abort and restart a
  transaction.
• Locking methods delay transactions only
• Optimistic schedulers are better than locking
  when many of the transactions are read only.

5
Timestamp TS(T)

• A unique number assigned to each transaction by
  the scheduler, must be issued in ascending order
• Use the system clock
• Maintain a counter
• No matter which method is used, the scheduler
  must maintain a table of currently active
  transactions and their timestamps.
• The timestamp order of transactions is also the
  serial order in which they must appear to execute.

6
Notations

• RT(X)
• the read time of X, the highest timestamp of a
  transaction that has read x
• WT(X)
• the write time of X, the highest timestamp of a
  transaction that has read x
• C(X)
• The commit bit for x, which is true if and only
  if the most recent transaction to write X has
  already committed. Used to prevent dirty read

7
Physically unrealizable behaviors

• The scheduler check that whenever a read or write
  occurs, what happens in real time could have
  happened if each transaction had executed
  instantaneously at the moment of its stamp. If
  not, the behavior is physically unrealizable
• read too later
• write too later

8
Read too later

• T tries to read X, but the write time of X
  indicate that the current value of X was written
  after T theoretically executed TS(T)ltWT(X)

Solution abort T when the problem is encountered
9
Write too later

• T tries to write X, but read time of X indicates
  that some other transaction should have read the
  value written by T but read some other values
  instead WT(X)ltTS(T)ltRT(X)

10
T could perform a dirty read if it reads X when
shown
11
A write is cancelled because of a write with a
later timestamp, but the writer then aborts
12
Summary

• To solve the above problems, a simple policy can
  be used
• When a transaction T writes a database element X,
  the write is tentative and may be undone if T
  aborts. The commit bit C(X) is set to false, and
  the scheduler makes a copy of the old value of X
  and its previous WT(X)

13
Choices of operations

• The scheduler, has the choice for a read or write
  from T
• Granting the request
• Abort T and restart T with a new timestamp
  (rollback)
• Delaying T and later deciding whether to abort T
  or to grant the request

14
Rules for timestamp-based scheduling

• 1. scheduler receives a request rT(X)
• a) TS(T)WT(X), the read is physically realizable
• i. C(X) is true, grant the request, if
  TS(T)gtRT(X), set RT(X)TS(T) otherwise do not
  change
• ii. C(X) is false, delay T until C(X) become true
  or the transaction that wrote X aborts
• b) TS(T)ltWT(X), the read is physically
  unrealizable. Rollback T

15
Rules for timestamp-based scheduling (Cont.)

• 2. the scheduler receives a request wT(X)
• a) TS(T)RT(X) and TS(T)WT(X) , the write is
  physically realizable and must be performed
• Write the new value for X
• Set WT(X)TS(T), and
• Set C(X)false
• b) TS(T)RT(X) and TS(T)ltWT(X) , the write is
  physically realizable, but there is already a
  later value in X.
• C(X) is true, the previous write is committed,
  ignore this write
• C(X) is false, delay T as in previous 1. a)ii
• c) TS(T)ltRT(X), the write is physically
  unrealizable, rollback T

16
Rules for timestamp-based scheduling (Cont.)

• 3. the scheduler receives a request to commit T.
• Find all X written by T, and set C(X)true
• The transactions waiting for X to be committed
  are allowed to proceed.
• 4. the scheduler receives a request to abort T or
  decides to rollback T.
• Any transactions waiting on X that T wrote must
  repeat its attempt to read or write, and
• See whether the action is now legal after the
  aborted transactions writes are cancelled.

17
Example 18.26
18
Multiversion timestamps

• Maintain old version of database elements in
  addition to the current version
• Allow reads rT(X) (otherwise have to abort) to
  proceed by reading the version of X that is
  appropriate for T.

19
Example 18.27
20
Multiversion timestamping

• As a new wT(X) occurs, if it is legal, a new
  version of X is created Xt, tTS(T)
• As a rT(X) occurs, the scheduler finds the
  version of X written immediately before T
  theoretically executed.
• Write times are associated with versions of an
  element
• Read times are also associated with versions
• When a version Xt has a write t such that no
  active transactions has a timestamp less that t,
  we may delete any versions of X previous to Xt.

21
A transaction tries to write a version of X that
would make events physically unrealizable
22
Example 18.28
23
Time stamps and locking

• Locking will frequently delay transactions as
  they wait for locks, and can even lead to
  deadlocks, thus timestamp works better in
  situations most transactions are read-only, or it
  is rare concurrent transactions try to read and
  write the same element.
• However, if concurrent transactions frequently
  read and write elements in common, then rollbacks
  in timestamping will be frequent, introduce even
  more delay than a locking system

24
Exercises

• 18.8.1 a) b)
• 18.8.2 a) b)

25
Concurrent control by validation

• The scheduler maintains a record of what active
  transactions are doing.
• Before a transaction starts to write values of
  database elements, it goes through a validation
  phase the sets of elements it has read and will
  write are compared with the write sets of other
  active transactions. If a risk of physically
  unrealizable, rollback this transaction

26
Architecture of a validation-based scheduler

• RS(T) read set
• WS(T) write set
• Transactions are executed in three phases
• Read read all the elements in its read set, and
  computes all the results to be written
• Validate comparing its read and write sets with
  those of other transactions. If validation fails,
  rollback, otherwise go to next phase
• Write write to database from its write set.

27
Sets maintained by the scheduler

• START the set of transactions that have started,
  but not yet completed validation
• For each transaction in this set, a record
  START(T) is maintained, the time at which T
  started
• VAL the set of transactions that have been
  validated but not yet finished the writing of
  phase 3.
• For each transaction in this set, a record
  START(T) as well as VAL(T) are maintained, the
  time at which T validated
• FIN the set of transactions that have completed
  phase 3.
• For each transaction in this set, a record
  START(T), VAL(T) and FIN(T) are maintained, the
  time at which T completed
• If FIN(T)ltSTART(U) for any active transaction U,
  the record for T can be eliminated

28
The validation rules

• Suppose a transaction U such that
• U is in VAL or FIN, U has validated
• FIN(U)gtSTART(T), U did not finish when T started
• RS(T) n WS(U) is not empty, it contains X

Solution rollback T
29
The validation rules (Cont.)

• Suppose a transaction U such that
• U is in VAL U has successfully validated
• FIN(U)gtVAL(T) U did not finish before T entered
  its validation phase
• WS(T) n WS(U) ? 0, let X be in both write sets.

Solution rollback T
30
Summary

• The previous two are the only situations in which
  a write by T could be physically unrealizable
• In summary, to validate a transaction T
• Check that RS(T) n WS(U) ? 0 for any previously
  validated U that did not finish before T started,
  i.e., if FIN(U)gtSTART(T)
• Check that WS(T) n WS(U) ? 0 for any previously
  validated U that did not finish before T
  validated, i.e., if FIN(U)gtVAL(T)

31
Example 18.29
32
Exercises

• 18.9.1 a) b)

33
Comparison

• Storage utilization
• Locks
• space in the lock table is proportional to the
  number of elements locked
• Timestamps varies
• Keep read and write times for all elements or
  eliminate all the times prior to the current
  earliest transaction
• Validation
• Space is used for timestamps and read/write sets
  for each currently active transaction, plus a few
  more other information

34
Comparison (Cont.)

• The amounts of space used by each approach is
  approximately proportional to the sum over all
  active transactions of the number of elements
  accessed
• Timestamping and validation may use slightly more
  space

35
Comparison (Cont.)

• Performance is determined by the interactions
  among transactions
• Locking delays transactions but avoid rollbacks
  even when interaction is high, other two methods
  rollback transactions (more serious and waste
  resource)
• If interaction is low, few rollbacks will be
  caused by timestamping and validation, thus they
  are superior than locking
• When rollback is necessary, timestamps catch some
  problems earlier than validation.