28-08-2012, 02:49 PM
Transaction Concepts
Transaction.ppt (Size: 587 KB / Downloads: 36)
Highlights of this Chapter
Basic concepts
ACID properties
Schedules
Locking
Transactions over composed services
Relaxing serializability
Extended transaction models
Transactions: 1
A transaction is a computation (i.e., program in execution) that accesses and possibly modifies a DB:
Can be interleaved with other transactions
But guarantees certain properties
The purpose of the transaction concept is to avoid the problems that may arise from interleaving
Transactions: 2
Operation: action on a data item
Transaction: set of operations performed in some partial order according to the specifying program
A transaction makes a set of operations appear as one logical operation
ACID Properties
These formalize the notion of one operation
(Failure) Atomicity—all or none—if failed then no changes to DB or messages
Consistency—don't violate DB integrity constraints: execution of the op is correct
Isolation (Atomicity)—partial results are hidden
Durability—effects (of transactions that "happened" or committed) are forever.
Transaction Lifecycle
A transaction goes through well-defined stages in its life (always terminating)
inactive
active (may read and write)
precommit (no errors during execution)
failed (errors)
committed (the DBMS decides this)
forgotten (the DBMS reclaims data structures)
Strict Schedules
In which an item can't be read or written until the previous transaction to write that item has committed (the aborted ones having been factored out).
Compare with ACA
This allows us to UNDO by restoring the before image
Serial Schedules
Transactions are wholly before or after others (i.e., one by one)
Clearly, we must allow for service requests to come in slowly, one-by-one
Thus, under independence of transactions (assuming each transaction is correct), serial schedules are obviously correct
Serializable Schedules
Interleaved schedules are desirable
why?
Those equivalent to some serial schedule. Here equivalent can mean
conflict equivalent —all pairs of conflicting ops are ordered the same way
view equivalent—all users get the same view
Achieving Serializability
Optimistically: Let each transaction run, but check for serializability before committing.
Pessimistically: Use a protocol, e.g., locking, to ensure that only serializable schedules are realized
Generally, the pessimistic approach is more common
Beyond Traditional Transactions
ACID transactions are applicable for
Brief, simple activities (few updates; seconds, at most)
On centralized architectures
By contrast, composed services and business processes involve tasks that
Are complex, i.e., long-running, failure-prone, multisite, with subtle consistency requirements
Cooperate with other tasks, computational and human
Must respect autonomy and heterogeneity