Title: NT/PV Model for Long Duration Transaction Systems
1NT/PV Model for Long Duration Transaction Systems
- Theoretical aspects of concurrency control in
long-duration transaction systems - It is based on the following ideas
- nested transactions
- predicate constraints
- multiple version of database states
Reference Formal Aspects of Concurrency
Control in Long-Duration Transaction Systems
Using the NT/PV Model, H.F. Korth and G.
Speegle, ACM TODS Vol 19, No. 3, Pages 492-535,
1994
2Problems
- Traditional transactions
- short, a fraction of a section
- simple
- New applications
- office information systems
- work flow systems
- web-based information systems
- Long-duration transaction systems
- human-interaction
- last very long, hours or days
3Intuitions
- Nested transactions
- a sub-transaction is a collection of database
access operations ( usually read and write )
which the rest of transaction views as a single
operation. - All the operations in a sub-transaction must be
executed or none at all - some operations in a subtransaction may also be a
sub-transaction of the next lower level - Nested transaction hierarchy
- leaves are read/write operations
- nonleaf nodes are subtransactions
- root models the execution of the entire system
4Example
Consider a round trip from Austin to Rochester
Trip
Rochester --gt Austin
R-gtC C-gt D D -gt A
5- Criteria for correctness
- Serializability
- A transaction transform the database from one
consistent state to another consistent state - the initial empty database is consistent
- execute one transaction at a time
- the final result is thus consistent
- Predicate constraint
- use predicate logic to specify the consistent
constraints - each transaction has
- precondition
- postcondition
- it is acceptable if one sub-transaction
invalidate the consistency constrains but another
will then restore it - a transaction can access to an inconsistent state
only if its precondition accepts it
6- Multiple Versions
- multiple versions of data items can be utilized
to achieve greater concurrency - overhead for keeping multiple versions
- mechanisms to determine which version to be read
We hope these mechanisms will help up to
increase concurrency
7Formal Models
- The standard transaction model
- E the set of all data items in the database
- dom(e) the domain of data item e for all e in E
- unique state S a database state with one value
for all e in E - D the set of all unique states
- P(D) assume P is a predicate specifying the
database consistency constraint, P(D) is the set
of all unique states which satisfy P. - a transaction t can be represented as a function
- t(P(D) to P(D)
8The NT/PV Model
- A database state S is a set of unique states
- D denotes the set of all database states.
- Given a database state S, a version state Vs is a
set of unique states which can be generated from
S. - A database with two items, each with two
versions, would have four unique database states
in the version state. - A transaction is defined as a mapping from one
database state to another database state - a mapping form an element of a version state to a
unique state
9- A predicate on a database state is satisfied if
any element in the version state satisfies it. - A transaction can be specified by two predicates
I and O such that for any database state S, if S
is in I(D) ( S satisfied I) then t(S) is in O(D)
( t(S) satisfied O). - Implementation of a transaction t is a pair (T,
P), where T is a set of transactions or
operations, and P is a partial order on T. - this models the nested transactions.
10Definition 1
- A transaction t is defined as a four-tuple
(T, P, I, O) - where (T, P) is the implementation and (I, O) is
the specification of t
11Definition 2
- An execution of a transaction T (T, P, I, O) is
a pair of (R, X), where R is a relation on T x T
such that - R is compatible with respect to P, i.e., if Ti lt
Tj in P, then Tj lt/ Ti in R - X is a mapping from T to a version state v such
that if Tk is in T then X(Tk) is the input state
of Tk. - X is used to specify which version is used as the
input for Tk - The execution of a transaction system T specifies
- the order in which all sub-transactions are
executed - which version will be used as the input for each
sub-transactions
12Definition 3
- An execution (R, X) of a transaction
t (T, P, I, O) is an NT/PV-correct
execution if - the last sub-transaction Tf in the execution
order satisfies O, and - for each other transaction Ti, X(Ti) satisfied
the I.
13Example
Consider the transaction Austin --gtRochester
Precondition Greg is not flying anywhere at
the departure time Postcondition Greg has a
series flight from A to R, and
the connecting time gt 30 minutes A-gtR
( T, P, I, O ) where T A-gtD, D -gt C,
C-gt R P an empty set I
Precondition O Postcondition
14Reservation 1
Incorrect because Gregs Flight left Dallas too
soon
Incorrect because the flights are not even
connected
15Standard Transaction
Definition 4 A transaction t (T, P, I, O) is
a standard transaction if (1) T is a
set of READ and WRITE operations (2)
P is a total order on T, (3) I O
All transactions preserve the consistency
A standard transaction is thus defined as a
sequence of database operations and its
operations preserves the consistency
Definition 5 A transaction t ( T, P, I, O )
is a standard transaction set if (1)
every Ti in T is a standard transaction,
(2) P is empty, and (3) I O
true
A standard transaction set is just a set of
standard transactions.
16- Given a transaction (T, P, I, O), and an
execution (R, X). - R is a standard relation on T if the order of
steps within a transaction is preserved in R - A schedule of a standard transaction set is
specified by a standard relation R. - A conflict relation R on T is defined as a
relation characterizing the conflict pair of
operators. That is, - Ti lt Tj if Read(Ti, A) before Write(Tj, A)
in R, where Read and Write denotes a pair of
conflict operations - An execution (R, X) for (T, P, I, O) is conflict
serializable if and only if R is acyclic.
Theorem An execution (R, X) for (T, P, I, O) is
conflict serializable if and only if R is
acyclic
17A Protocol for NT/PV-Correct Execution
- Version Predicate Correct (VPC) protocol
- Leaf Transaction Execution
Lock Held
Lock Requeste
Lock Compatibility Matrix
18State transition for leaf transactions
Init
Check
Block
Execute
Commit
Abort
19The Protocol
- Init a leaf transaction enters Init when its
prarent transaction submits a begin transaction
operation - specifies I and O
- request Rv ( read for validation) locks
- goto Block or Check, depending on Rv locks
- Block waiting for Rv or Read locks
- waiting is short
- after waiting is over, enter
- Init if it is waiting for Rv
- Execute if it is waiting for Read,
- Check if forced by another transaction
20The Protocol (continued)
- Check to find a correct set of versions to read,
and it will - enter Eexcute if this set of versions is found
- ramains in Check if the set cannot be found
- abort in some cases
- Execute
- a write request is always granted and the write
lock released as soon as possible - it may cause inconsistency and thus leads to
re-evaluation - a read request is granted based on the
compatibility matrix - the transaction enters Block if the write lock is
held by others
21The Protocol (continued)
- Commit
- A transaction may commit if it finishes all its
steps and releases all its locks - Abort
- it has to rollback all its operations
- Leaf termination
- only sibling transactions may see the results of
a transaction even after it commits - a committed transaction has to abort if its
parent aborts
22Non-Leaf Transactions
- The transition graph is a subset of that of leaf
transactions - the only operation is start subtransactions
- it inherits all read set of it subtransactions
- the transaction cannot precede committed
subtransactions - Reeval of a non-leaf transaction will reassign
the versions to its lower level transactions
which may cause them to be re-evaluated or even
aborted.
23Main Results
- The VPC protocol allows only NT/PV-correct
executions