-- Practice Final Thread
Question 5: Kim Pham, Stanley Plagata, Elena Pearson
Timestamp scheduling: give each transaction and database element a timestamp and compare these to determine if the schedule is equivalent to the serial schedule given by the transactions' timestamps.
In timestamp scheduling, the scheduler can grant, delay, or abort a transaction
Timestamp Scheduling:
1/ Read request:
- if timestamp > time write -> the read is realizable
- if committed -> grant the request & update timestamp
else delay
- if timestamp < time write -> non realizable -> rollback
- abort
2/ Write request:
- if timestamp >= read time and timestamp >= write time, write is realizable
- write, reset write time = timestamp and commit to false
- if timestamp >= read time and timestamp < write time, write is realizable but there is a value in X
- if Committed -> ignore write, otherwise delay until transaction commit or abort
- if timestamp < read time -> roll back
Multiversion Scheduling:
- Write request create new versions of the database elements
- Read request: read from a version that is older from the current transaction timestamp
- Write time and read time are associated with versions of an element
Example:
Timestamp scheduling: A transaction with a smaller timestamp attempt to read from a database element with a greater last write time, then the transaction would abort
Multiversion scheduling:
Supposed there are 2 version of X: X_50 and X_100
When T1 read from X at time=80, it read X_50
Supposed a transaction T2 that started at time=60 attempted to change X at time=90, it would create an inconsistent (T1 should have read X_90)
So T2 would have to abort
Question 5: Kim Pham, Stanley Plagata, Elena Pearson
Timestamp scheduling: give each transaction and database element a timestamp and compare these to determine if the schedule is equivalent to the serial schedule given by the transactions' timestamps.
In timestamp scheduling, the scheduler can grant, delay, or abort a transaction
Timestamp Scheduling:
1/ Read request:
- if timestamp > time write -> the read is realizable
- if committed -> grant the request & update timestamp
else delay
- if timestamp < time write -> non realizable -> rollback
- abort
2/ Write request:
- if timestamp >= read time and timestamp >= write time, write is realizable
- write, reset write time = timestamp and commit to false
- if timestamp >= read time and timestamp < write time, write is realizable but there is a value in X
- if Committed -> ignore write, otherwise delay until transaction commit or abort
- if timestamp < read time -> roll back
Multiversion Scheduling:
- Write request create new versions of the database elements
- Read request: read from a version that is older from the current transaction timestamp
- Write time and read time are associated with versions of an element
Example:
Timestamp scheduling: A transaction with a smaller timestamp attempt to read from a database element with a greater last write time, then the transaction would abort
Multiversion scheduling:
Supposed there are 2 version of X: X_50 and X_100
When T1 read from X at time=80, it read X_50
Supposed a transaction T2 that started at time=60 attempted to change X at time=90, it would create an inconsistent (T1 should have read X_90)
So T2 would have to abort