1 / 43

Transaction Concepts and Process Specifications

Transaction Concepts and Process Specifications. Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005. Highlights of this Section. Basic concepts ACID properties Schedules Locking Transactions over composed services Processes

jamuna
Download Presentation

Transaction Concepts and Process Specifications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Highlights of this Section • Basic concepts • ACID properties • Schedules • Locking • Transactions over composed services • Processes • Workflows • Business Process Language BPEL4WS (WS-BPEL) Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  3. 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? Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  4. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  5. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  6. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  7. 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) Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  8. 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? Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  9. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  10. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  11. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  12. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  13. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  14. 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) Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  15. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  16. Two-Phase Locking (2PL) • 2PL considers 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 strict schedules (also ACA by definition) • But can deadlock • Conservative 2PL: takes all locks early; risks starvation Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  17. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  18. 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? Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  19. 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? Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  20. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  21. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  22. Transactions over Composed Services Composed service as a transaction Expedia 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 Direct users service service United Sheraton LDB1 LDB2 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  23. 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 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  24. 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! Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  25. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  26. Compositional Deadlock Easy to construct scenarios in which a deadlock is achieved. • 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  27. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  28. 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) Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  29. 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  30. 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) Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  31. Transaction 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 Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  32. Highlights of this Section • Processes • Describing Dynamics with UML • Workflows • Business Process Languages • BPEL4WS (WS-BPEL) • ebXML • RosettaNet • PSL: Process Specification Language Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  33. Processes and Workflows Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  34. Process Abstractions Orchestration: A process is a partial order of actions (activity graph, script) under the control of a central conductor; akin to a workflow [Global; central] Choreography: A process is an exchange of messages among participants; akin to a conversation as described by WSCL, WS-CDL, ebBP [Global; distributed] Collaboration: A process is a joint set of activities among business partners [Local; distributed] Workflow: narrower concept than process; emphasizes control and data flows from a central perspective; usually tool-specific and focused on human tasks Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  35. Telecommunications Order Processing Older workflow tools support specialized (ad hoc) notations Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  36. Describing Dynamics with UML Practically identical to BPMN (Business Process Modeling Notation) and WS-BPEL (Business Process Execution Language) • Sequence: a transition from one activity to the next in time • Branch: a decision point among alternative flows of control • Merge: where two or more alternative flows of control rejoin • Fork: a splitting of a flow of control into two or more concurrent and independent flows of control • Join: a synchronization of two or more concurrently executing flows of control into one flow Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  37. UML Activity Diagram Implementation of a vendor’s purchase process Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  38. Flow Interoperability Patterns • Among others: • Chained • Nested • Synchronized • What guarantees would you obtain from each? • How would you accommodate exceptions in each? Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  39. WS-BPEL Metamodel Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  40. Process as a Composite Web Service Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  41. Stock Quote Service in WS-BPEL <process name="simple" targetNamespace="urn:stockQuoter" xmlns:tns="urn:stockQuoter" xmlns:sqp="http://tempuri.org/services/stockquote" xmlns=&BPEL;/> <containers> <container name="request" messageType="tns:request"/> <container name="response" messageType="tns:response"/> <container name="invocationRequest" messageType="sqp:GetQInput"/> <container name="invocationResponse" messageType="sqp:GetQOutput"/> </containers> <partners> <partner name="caller" serviceLinkType="tns:StockQuoteSLT"/> <partner name="provider" serviceLinkType="tns:StockQuoteSLT"/> </partners> <sequence name="sequence"> <receive name="receive" partner="caller" portType="tns:StockQuotePT" operation="wantQuote" container="request" createInstance="yes"/> <assign> <copy> <from container="request" part="symbol"/> <to container="invocationRequest" part="symbol"/> </copy> </assign> <invoke name="invoke" partner="provider" portType="sqp:StockQuotePT" operation="getQuote" inputContainer="invocationRequest" outputContainer="invocationResponse"/> <assign> <copy> <from container="invocationResponse" part="quote"/> <to container="response" part="quote"/> </copy> </assign> <reply name="reply" partner="caller" portType="tns:StockQuotePT" operation="wantQuote" container="response"/> </sequence> </process> Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  42. Exercise: Exception in a Process Recording student registration • Assume that each database management system supports two-phase commit for transactions • Task #2 checks that the student has completed the necessary prerequisites for all the courses for which the student is registering Consider a scenario where Tasks #3, #4, #5 succeed, but Task #2 fails • As the system administrator, what operations would you have to perform in order to restore consistency to your system? • How would you modify the process to prevent problems such as this from occurring? Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

  43. Process Summary • In virtually all serious applications of SOC, services are composed into processes • Current approaches for process modeling are based on workflow abstractions • WS-BPEL enables specification of processes • ebXML also considers the life cycle of processes • RosettaNet is an application of ebXML • Flows interact in various ways • Exceptions in flows can be handled via (extended) transactions or through application-specific means (where interesting patterns can arise) Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

More Related