chapter 11: transaction concepts
Post on 12-Jan-2016
39 Views
Preview:
DESCRIPTION
TRANSCRIPT
Chapter 11:Transaction Concepts
Service-Oriented Computing: Semantics, Processes, Agents– Munindar P. Singh and Michael N. Huhns, Wiley, 2005
Chapter 11 2Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Highlights of this Chapter
Basic concepts ACID properties Schedules Locking
Transactions over composed services
Relaxing serializability Extended transaction models
Chapter 11 3Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Motivation
As services are employed for serious purposes, they will inevitably update information resources
Can we be sure that such updates preserve integrity?
What about when multiple services need to work together?
What about when the services are involved in a long-lived activity?
Chapter 11 4Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Transactions: 1
A transaction is a computation (i.e., program in execution) that accesses and possibly modifies a database: Not the source code; not the binaries Can be interleaved with other transactions But guarantees certain correctness
properties
The purpose of the transaction concept is to avoid the problems (“race conditions”) that may arise from interleaving
Chapter 11 5Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Transactions: 2
Operation: action on a data item Transaction: set of operations
performed in a partial order according to the specifying program Assume total order here for simplicity
A transaction makes a set of operations appear as one logical operation
Chapter 11 6Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
ACID Properties
Properties that capture the consequences of a transaction being treated as one operation
(Failure) Atomicity—all or none—if failed then no changes to DB or messages This is the vernacular notion of “transaction”
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
Programmer-DBMS Contract
If each transaction is individually correct [programmer], then all transactions are jointly correct [DBMS]
Chapter 11 7Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Chapter 11 8Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Transaction Lifecycle
A transaction goes through well-defined stages in its life (always terminating) Inactive Active (may read and write)
Entire business logic takes place here Precommit (no errors during execution;
needed for mutual commitment protocols)
Failed (errors) Committed (the DBMS decides this) Forgotten (the DBMS reclaims data
structures)
Chapter 11 9Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Schedules
Schedules are histories of computations showing all events of interest
Schedule of T1...Tn has all ops of T1...Tn in the same order as within each Ti, but interleaved across Ti to model concurrency Includes active transactions Typically a partial order among events
Two challenges What are the bad schedules? How can the DBMS prevent them?
Chapter 11 10Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Conflict
Order-sensitivity of operations Two operations of different
transactions, but on the same data item, conflict if Their mutual order is significant, i.e.,
determines at least one of the following:
The final value of that item read by future transactions
The value of the item as read by present transactions
Chapter 11 11Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Serial Schedules
Transactions are wholly before or after others (i.e., occur 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
Chapter 11 12Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
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
Chapter 11 13Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
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
Chapter 11 14Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Locks
Lock item x while using item x Binary: at most one party may lock x
Lock(x): acquire the lock Computation hangs until lock(x) returns, i.e., the
lock is acquired Unlock(x): relinquish the lock Gives mutual exclusion but restrictive
Chapter 11 15Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Multimode Locks
When one party has an exclusive lock, no other party may have an exclusive or a shared lock
Shared-lock(x) needed for read(x) Others can also hold a shared lock
Exclusive-lock(x) needed for write(x) No one else can concurrently hold a shared
or exclusive lock Can be upgraded (read to write) or
downgraded (write to read)
Chapter 11 16Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Achtung!
By itself, using locks does not guarantee serializability What is an example of a bad schedule
obtained while using locks? A locking protocol, i.e., how locks
are acquired and released, is critical
That is, locks on different data items must be related
Chapter 11 17Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Two-Phase Locking (2PL) Two phases in a transaction’s life
Growing phase: acquire but not release locks Shrinking phase: release but not acquire
locks Guarantees serializability, but can
deadlock Strict 2PL releases all locks at once when
the transaction commits or rolls back Ensures rigorous schedules (to be discussed) But can deadlock
Conservative 2PL: takes all locks early; risks starvation
Chapter 11 18Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Reading From
T1 reads from T2 if the schedule contains a subsequence w2(x)...r1(x), where
w2 is the first write on x going backwards from r1(x)
a2 doesn’t occur between w2 and r1
Chapter 11 19Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Recoverable Schedules
In which a transaction commits after all transactions it read from have committed In terms of the ACID properties, what
is the risk in allowing a nonrecoverable schedule?
Chapter 11 20Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Avoid Cascading Aborts (ACA)
In which a transaction does not read from uncommitted transactions
What is the risk in allowing such reads?
Are cascading aborts Legal? Expensive?
Chapter 11 21Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
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
Chapter 11 22Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Rigorous Schedules
In which an item can't be read or written until the previous transaction to read or write that item has committed
Compare with strict schedules
Chapter 11 23Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Distributing ACID Transactions
ACID transactions are applicable for Brief, simple activities (few updates;
seconds, at most) On centralized architectures
Without distribution, ACID transactions would be a nonstarter outside of a single DBMS
Chapter 11 24Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Closed-Nested Distributed Transactions
ACID transactions can be implemented in distributed settings
Consider two or more subtransactions, conceptually organized as a tree Ensure atomicity through two-phase commit
(2PC) Ensure isolation so that results are not
exposed till the global transaction commits As in WS-AtomicTransactionWhy would ACID transactions ever be
useful for SOC?
Chapter 11 25Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Transactions over Composed Services
Assume each service ensures serializability locallyTwo main kinds of service agreements are possible: Execution, e.g., LDB retains full control on
execution even if in conflict with CTM Communication, e.g., LDB decides what (control)
information to release
Composed Transaction Manager
LDB1 LDB2
service service
Composed service as a transaction
DirectusersUnited Sheraton
Expedia
Chapter 11 26Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Compositional SerializabilityTransactions throughout the system should be serializable CTM ensures that the composed transactions are
serializable This doesn't guarantee compositional serializability,
because of indirect conflicts: CTM does T1: r1(a); r1(c) CTM does T2: r2(b); r2(d) LDB1 does T3: w3(a); w3(b) LDB2 does T4: w4(c); w4(d) Since T1 and T2 are read-only, they are serializable. LDB1 sees S1=r1(a); c1; w3(a); w3(b); c3; r2(b); c2
LDB2 sees S2=w4(c); r1(c); c1; r2(d); c2; w4(d); c4 Each LDB has a serializable schedule; yet jointly they put
T1 before and after T2
Notice we would have lots of potential compositions, so the problem is worse
Chapter 11 27Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Strawman 1: Tickets
Compositional serializability fails because of local conflicts that the CTM does not see
Fix by always causing conflicts--whenever two composed transactions execute at a site, they must conflict there. Indirect conflicts become local conflicts visible to the LDB Make each composed transaction increment a
ticket at each site Downside:
Causes all local subtransactions of a transaction to go through a local hotspot
Composed transactions are serialized, but only because many are aborted!
Chapter 11 28Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Strawman 2: Rigorous SchedulingHold read and write locks till end (no
tickets) Check that this prevents the bad example The CTM must delay all commits until all
actions are completed possible only if allowed by LDB requires an operation-level interface to LDB
Downside: Causes all sites to be held up until all are
ready to commit Essentially like the 2PC approach
Chapter 11 29Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Possible Methodology
When no cross-service constraints apply, local serializability is enough
Split data into local and shared partitions LDB controls local data CTM controls shared (local transactions can
read, but write only via CTM) Downside: doesn’t work in all cases
All shared data is managed through a special service
Only for the most trivial compositions
Chapter 11 30Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Compositional Atomicity
Can succeed only if the services restrict their autonomy through service-level agreements, e.g., 2PC
Otherwise, the services May not release their prepare-to-
commit state May not participate in a mutual
commit protocol such as 2PC
Chapter 11 31Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Compositional Deadlock
Assume LDB1 and LDB2 use 2PL. If a deadlock is formed
Solely of upper-level transactions, then the CTM may detect it
Of a combination of local and upper transactions, then CTM won't know of it LDBs won't share control information
Chapter 11 32Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Compositional Atomicity & Durability
Without 2PC, what would happen when a CT fails?
Each service individually ensures “correctness” according to its local policies
Achieve weaker atomicity, durability via: Redo: rerun the writes from log Retry: rerun all of a subtransaction Compensate: semantically undo all other subtransactions
Chapter 11 33Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Beyond ACID Transactions
Composed services feature in business processes, which Cross administrative boundaries Are complex, i.e., long-running, failure-
prone, multisite, with subtle consistency requirements
Cooperate with other processes, involving computational and human tasks
Respect autonomy and heterogeneity of components
Chapter 11 34Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Extended Transactions
Extended transaction models relax the ACID properties by modifying various features
Allowing open nesting, wherein partial results are revealed (newer, non-ACID)
Atomicity, e.g., contingency procedures, to ensure “all”
Consistency restoration, e.g., via compensation, to ensure “none”
Constraints among subtransactions, such as Commit dependencies Abort dependencies
Ultimately, a transaction must be atomic (albeit in a relaxed sense)
Chapter 11 35Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Compensation
Something that semantically undoes the effect of a transaction
Common in business settings Compensations are necessary
even if imperfect Deposit and withdraw Reserve and cancel Ship and return Pay and refund
Chapter 11 36Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Extended Transaction Models
The ones we consider Sagas Flex Transactions DOM Transactions
Several others, mostly either Implementation-specific or Narrower than the above
General-purpose scheduling approach (Chapter 14)
Chapter 11 37Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Sagas
Guarantee atomicity but not isolation Execute a sequence of transactions
If all transactions succeed, then good (all)
If any transaction fails, undo all previous in reverse order (none)
Assumptions Compensations succeed (eventually) for
the first several members of sequence Retries succeed for the last several
Chapter 11 38Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Distributed Object Management
Avoid partial failure of a multitransaction via either total success or total failure
Total success Redo from log Retry Contingency procedures
Total failure Undo from log Compensations
Uses ordering constraints and vital subtransactions
Chapter 11 39Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and
Michael Huhns
Chapter 11 Summary We need a means to ensure that services behave
reasonably, i.e., by ensuring the integrity of data Database management provides the notion of
transactions for this purpose Distributed transactions can apply in closed settings Ensuring the ACID properties is infeasible in open
settings Extended transaction models are needed
Simple constructs of such models are helpful, and being encoded in standards
Often, an important application is process management (coming up)
More sophisticated behaviors require increased intelligence in modeling and enactment, also to be discussed later
top related