Chapter 11: Transaction Concepts Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005

Chapter 112Service-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 113Service-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 114Service-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 115Service-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 116Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns ACID Properties If programmers guarantee correctness of individual transactions, then DBMS guarantees correctness of any set of them The ACID properties formalize the notion of a transaction behaving 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

Chapter 117Service-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 118Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns Schedules Schedules are histories of computations showing all events of interest Schedule of T 1...T n has all ops of T 1...T n in the same order as within each T i, but interleaved across T i 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 119Service-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 1110Service-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 1111Service-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 1112Service-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 1113Service-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 1114Service-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 1115Service-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 1116Service-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 1117Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns Reading From T 1 reads from T 2 if the schedule contains a subsequence w 2 (x)...r 1 (x), where w 2 is the first write on x going backwards from r 1 (x) a 2 doesn’t occur between w 2 and r 1

Chapter 1118Service-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 1119Service-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 1120Service-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 1121Service-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 1122Service-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 1123Service-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-AtomicTransaction Why would ACID transactions ever be useful for SOC?

Chapter 1124Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns Transactions over Composed Services Assume each service ensures serializability locally Two 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 LDB1LDB2 service Composed service as a transaction Direct users United Sheraton Expedia

Chapter 1125Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns Compositional Serializability Transactions 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 T 1 : r 1 (a); r 1 (c) CTM does T 2 : r 2 (b); r 2 (d) LDB1 does T 3 : w 3 (a); w 3 (b) LDB2 does T 4 : w 4 (c); w 4 (d) Since T 1 and T 2 are read-only, they are serializable. LDB1 sees S 1 =r 1 (a); c 1 ; w 3 (a); w 3 (b); c 3 ; r 2 (b); c 2 LDB2 sees S 2 =w 4 (c); r 1 (c); c 1 ; r 2 (d); c 2 ; w 4 (d); c 4 Each LDB has a serializable schedule; yet jointly they put T 1 before and after T 2 Notice we would have lots of potential compositions, so the problem is worse

Chapter 1126Service-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 1127Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns Strawman 2: Rigorous Scheduling Hold 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 1128Service-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 1129Service-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 1130Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns Compositional Deadlock Assume LDB 1 and LDB 2 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 1131Service-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 1132Service-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 1133Service-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 1134Service-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 1135Service-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 1136Service-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 1137Service-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 1138Service-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