1 / 20

Dagstuhl Seminar on Atomicity, 2006

Atomicity and the Commutativity of Actions P. M. Melliar-Smith and Louise E. Moser Department of Electrical and Computer Engineering University of California, Santa Barbara. Dagstuhl Seminar on Atomicity, 2006. Some of the Successes of Current Computing Technology. The Internet World Wide Web

marly
Download Presentation

Dagstuhl Seminar on Atomicity, 2006

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. Atomicity and the Commutativity of ActionsP. M. Melliar-Smith and Louise E. MoserDepartment of Electrical and Computer Engineering University of California, Santa Barbara Dagstuhl Seminar on Atomicity, 2006

  2. Some of the Successes ofCurrent Computing Technology • The Internet • World Wide Web • Distributed Systems • Concurrency Control • Atomic Transactions

  3. Web Services • Wonderful objective • Couple together the computer systems of enterprises world-wide, so that they can interoperate • No prior arrangements • No prior knowledge of each other • No human intermediation • Potential major impacts on • Computing • Business practices • International relationships

  4. Example • I want to buy 1,000 tons of chicken feed (or 10 jumbo jets or 10,000 DVD players) • Contact Cargill to get price and delivery • Contact CitiGroup to get finance • Contact Mississippi Barge for shipping • Contact Memphis Grain Depot for storage • Cargill might need to contact its suppliers • I don't want to commit to any of this until everybody is lined up Classic Atomic Transaction except that’s not how it’s done

  5. Distributed Transaction • Theory of Distributed Transactions • Good theory exists in academia • Little use in practice • Risk of locking records too long • Lack of trust in other participants

  6. Distributed Transactions and Web Services • Consequence • Compensating Transactions • Violates ACID Properties

  7. Advantages of Atomic Transactions • Separation of Individual Transactions • Each transaction can be designed separately, even though they will be executed concurrently • A problem in one transaction can be recovered, without messing up other transactions • Atomic Transactions work really well • Easy to understand and use • Allow the construction of complex systems • Good efficiency, high concurrency • Reasonable development costs • Acceptable levels of reliability We need to achieve the same benefits for distributed systems built from Web Services

  8. Business Activity Business Activity –Sequence of actions at several sites • If, at each site, the actions of the activities commute, then the activities are atomic [Weihl88] Many actions do not commute but Typical distributed enterprise actions, such as are implemented by Web Services, can be made to commute

  9. Reservations • I want to buy 1,000 tons of chicken feed • Reserve 1,000 tons of chicken feed at Cargill • Reserve finance from CitiGroup • Reserve shipping from Mississippi Barge • Reserve storage at Memphis Grain Depot • All ducks lined up • Confirm purchase at Cargill • Confirm finance and payment at CitiGroup • Confirm shipping at Mississippi Barge • Confirm storage at Memphis Grain Depot

  10. Structure • Business Activity • Sequence of actions • Actions typically at multiple sites • May involve multiple actions on the same data item • Finite with a start and an end • Action • Part of a single Business Activity • Local to one site • One or more data items

  11. Structure • Transaction • Sequence of actions • Actions potentially at multiple sites • ACID • Local Transaction • A single action at a single site • ACID

  12. Preceding and Concluding Actions • The first action of a Business Activity on a data item (record) causes a preceding action • Preceding action imposes a context or constraint • Imposed on the actions of the Business Activity, and on the data item, to ensure that the actions of the Business Activity on that data item commute with the actions of other Business Activities on that data item • Limit actions of the Business Activity to amount of resources allocated to it • Reduce resources available to other subsequent Business Activities • Actions of a Business Activity on a data item are followed by a concluding action • Record effects of the actions • Remove constraints • Preceding and concluding actions are strictly local

  13. Constraints • Typical enterprise actions involve only addition and subtraction • Addition and subtraction commute, provided that • Numbers do not become negative • Constraint imposed by preceding action ensures that numbers do not become negative • i.e., Reservations • Local sequential order on preceding action suffices to guarantee commutativity

  14. Example • Inventory is 1,000 units • First action: Intend to buy 100 units • Preceding action: • Record reservation of 100 units for 1 minute • Reduce available inventory to 900 units • More actions to arrange finance, shipping • Concluding action to confirm purchase: • Delete reservation record • Confirm inventory reduction by amount actually purchased • Concluding action to cancel reservation: • Delete reservation record • Restore reserved items to inventory

  15. Advantages • Commutativity supports • Separation of business activities • Easy design of recovery actions and abort actions • Reservations are • Easy to understand and to program • Match existing business processes • Allow increased concurrency

  16. Reservation Protocols for Web Services Explicit Protocol • client to server Request Service • server to client Offer Reservation • client to server Activate Reservation • both client and server Provide Service • client to server Complete Activity, or • client to server Abort Activity

  17. Reservation Protocols for Web Services Implicit Protocol • client to server Request Service, with transaction context • server to client Register as participant in transaction • Server does not actually participate in atomic transaction, rather it exploits commutativity • Specify deadline during registration • both client and server Provide Service • client to server Commit, or • client to server Abort

  18. Reservations • Competitive Quotations • Quotation and Reservation are combined • Confirm reservation for selected quotation • Decline other reservations and quotations • Fee for Reservation • Fees are current practice for major reservations • If reservation is for a short time, fee can be small or zero • Upper Bounds, as well as Lower Bounds • Push rather than Pull (e.g., General Motors offers 20 SUVs at advantageous price) The reservation protocol structure is the same, but the effects depend on the business activity i.e., The concluding action adds to the inventory

  19. Problems • Timeouts incur a risk of race conditions • Use different timeouts at client and server • Deadlocks are still possible • Use same deadlock detection algorithms as for transactions • Failure of the Coordinator • Three phase commit is too expensive • Coordinator replication is too expensive

  20. Conclusion • Reservations and Commutativity can restore Order to Web Services • Easy to understand and use • Consistent with business practices • Users retain control over their resources • Low overhead because strictly local Thank You Michael Melliar-Smith – pmms@ece.ucsb.edu Louise Moser – moser@ece.ucsb.edu

More Related