WIXLIB

3/24/07Copyright 2007 Philip A. BernsteinCSEP 545 Transaction ProcessingPhilip A. Bernstein1. Introduction1

3/24/071. The Basics2. ACID Properties3 Atomicity and Two-Phase Commit3.4. Performance5. Styles of SystemOutline2

3/24/07 Reserve an airline seat. Buy an airline ticketWithdraw money from an ATM.Verify a credit card sale.Order an item from an Internet retailerPlace a bid at an on-line auctionSubmit a corporate purchase order The execution of a program that performs anadministrative function by accessing a shareddatabase, usually on behalf of an on-line user.Examplesp31.1 The Basics - What’s a Transaction?

3/24/07 Reliability - system should rarely failAvailability - system must be up all the timeResponse time - within 1-2 secondsg p - thousands of transactions/secondThroughputScalability - start small, ramp up to Internet-scaleSecurity – for confidentiality and high financeConfigurability - for above requirements low costAtomicity - no partial resultsDurability - a transaction is a legal contractDistribution - of users and dataThe “ities” are What MakesTransaction Processing (TP) Hard4

3/24/07 It’s a huge slice of the computer systemmarket. One of the largest applications ofcomputers. Most medium-to-large businesses use TP fortheir production systems. The business can’toperate without itit. It’s at the core of electronic commerceWhat Makes TP Important?5

3/24/07 TP system makes it easy to program transactions TP system has tools to make it easy to manage– is an independent unit of work– executes exactly once, and– produces permanent results. TheTh TP systemt ensures thatth t eachh transactiontti– Enter a request from a browser or other display device– The system performs some application-specific work,which includes database accesses– Receive a reply (usually, but not always) User’s viewpointTP System Infrastructure6

3/24/07End-UserTransaction ServerDatabase System(routes requests andsupervises their execution)Request ControllerrequestsFront End ProgramBack-End(Server)Cli tClientDefines System and Application StructureTP System Infrastructure 7

3/24/07– hundreds of thousands of active display devices– plus indirect access via Internet– tens of thousands of transactions per second, peak A large-scale example: airline reservations– 0-30 disk accesses– 10K - 1M instructions executed– 2-20 messages Typically 100 transaction types per application Transaction size has high variance. Typically,System Characteristics8

3/24/07 Contributing factors– failures due to environment, system mgmt, h/w, s/w– recovery time9 Fraction of time system is able to do useful work Some systems are very sensitive to downtime– airline reservation, stock exchange, telephone switching– downtime is front page newsDowntimeAvailabilityy95.8%1 hour/day1 hour/week99.41%1 hour/month99.86%1 hour/year99.9886%1 hour/20years99.99942%Availability

3/24/07servers and 10Ks of displays– App Server helps system engineer deploy it on the Internet,accessible from web browsers– App Server helps system engineer deploy it to 10s/100s of– E.g. application developer writes programs to debit a checkingaccount and verify a credit card purchase. A software product to create, execute and manage TPapplications Formerly called TP monitors. Some people sayApp Server TP monitor web functionality. Programmer writes an app to process a single request.App Server scales it up to a large, distributed systemApplication Servers10

3/24/07 Enterprise Java Beans, IBM Websphere,Microsoft .NET (COM ), BEA Weblogic,Oracle Application Server– an application programming interface (API)(e.g., Enterprise Java Beans)– tools for program development– tools for system management (app deployment,fault & performance monitoring, user mgmt, etc.) Components includeApplication Servers (cont’d)11

3/24/07Transaction ServerNetworkTransaction ServerRequest ControllerQueuesFront End ProgramMessageInputs Boxes below are distributed on an intranetApp Server Architecture, pre-Web12

ControllerATMBank Branch 500Credit CardAccountsATMBank Branch 2RequestControllerATMCIRRUSAccountsATMBank Branch 1Automated Teller Machine(ATM) Application Example

3/24/07Transaction Serverintranetother TPsystemsTransaction ServerRequest ControllerQueuesWeb ServerMessageInputsApplication Server Architecture14

putersRequestControllerInternet Retailer 15

3/24/07MusicElectronicsWebServerWeb ServiceTheInternetComputersRequestControllerToys Web services - interface and protocol standardsto do app server functions over the internet.Service Oriented Architecture (SOA)Weeb Service16

3/24/07 EAI and Application Servers address a similarproblem, with different emphasis IBM Websphere MQ, TIBCO, Vitria, SeeBeyond– A queuing system– A message mappingi systemt– Application adaptors (SAP, PeopleSoft, etc.) A software product to route requests betweenindependent application systems. Often includeEnterprise Application Integration(EAI)17

3/24/07ATMCheckingAccountsATM18LoanAccountsEAI RoutingATMBank Branch 500Credit CardAccountsQueuesATMBank Branch 2EAI RoutingATMCIRRUSAccountsQueuesATMBank Branch 1ATM Examplewith an EAI System

A workflow script languageWorkflow script interpreter and schedulerWorkflow trackingMessage translationApplication and queue system adaptors3/24/07 Transaction-centric vs. document-centric Structured processes vs. case management IBM Websphere MQ Workflow, Microsoft BizTalk, SAP,Vitria, Oracle Workflow, FileNET, Documentum, .––––– A software product that executes multi-transactionlong-running scripts (e.g. process an order) Product componentsWorkflow, or Business Process Mgmt19

LoanAccountsCredit cardAccounts3/24/07 Heterogeneous query systems (mediators).It’s database system software, but It’s similar to EAI with more focus on datatransformations than on message mgmt There are hybrids, e.g., BEA AquaLogicCheckinggAccountsQuery MediatorData Integration Systems(Enterprise Information Integration)20

Application ServerEnterprise Application IntegrationBusiness process management (aka Workflow)Enterprise Server Bus3/24/07 New ones all the time, that defy categorization.–––– In summary, there are many variations thatpackage different combinations of middlewarefeatures.Transactional Middleware21

3/24/07HardwareOperating systemDatabase systemApplication Server This course focuses primarily on theDatabase System and Application Server– Getting all those components to work togetherto produce a system with all those “ilities”. TP is partly a system engineering problem–––– TP is partly a component product problemSystem Software Vendor’s View22

3/24/07!1. The Basics2. ACID Properties3 Atomicity and Two-Phase3.Two Phase Commit4. Performance5. Styles of SystemOutline23

3/24/07––––Atomicity - all or nothingConsistency - preserve database integrityIsolation - execute as if they were run aloneDurability - results aren’t lost by a failure Transactions have 4 main properties1.2 The ACID Properties24

3/24/0725– For database operations, restore the data’s previous valuefrom before the transaction– But some real world operations are not undoable.Examples - transfer money, print ticket, fire missile Commit and abort are irrevocable actions. An Abort undoes operations that already executed– E.g. in a money transfer, debit one account, credit theother. Either debit and credit both run, or neither runs.– Successful completion is called Commit.– Transaction failure is called Abort. All-or-nothing, no partial results.Atomicity

3/24/07Deferred operationnever gets executedT1: Start. . .CommitDispense MoneyT1: Start. . .Dispense MoneyCommitSystem crashesSystem crashesTransaction abortsMoney is dispensedExample - ATM Dispenses Money(a non-undoable operation)26

3/24/07User reads output U entersUsert iinputt27BraintransportT2: StartGet input from display.CommitT1: Start.Display output.If error, AbortReading Uncommitted Output Isn’tUndoable

3/24/07" A well-designed TP application should have acompensation for every transaction type28– E.g. Certain money transfers– E.g. Fire missile, cancel contract– Contract law talks a lot about appropriate compensations Not all transactions have complete compensations– “Adjustment” in a financial system– Annul a marriage A transaction that reverses the effect of anothertransaction (that committed). For example,Compensating Transactions

3/24/07" Consistency preservation is a property of atransaction, not of the TP system(unlike the A, I, and D of ACID) If each transaction maintains consistency,then serial executions of transactions do too.29– Referential integrity - E.g. each order references anexisting customer number and existing part numbers– The books balance (debits credits, assets liabilities)Every transaction should maintain DB consistencyConsistency

3/24/07 ri[x] Read(x) by transaction Tiwi[x] Write(x) by transaction Tici Commit by transaction Tiai Abort by transaction TiA history is a sequence of such operations,in the order that the database systemprocessed them.Some Notation30

3/24/07T2: Start;B Read(x);C Read(y);If (B C 1) then B B - 1;Write(x, B);Commit;– e.g. try it with x 4 and y 2 initially Consistency predicate is x y. Serial executions preserve consistency.Interleaved executions may not. H r1[x] r2[x] r2[y] w2[x] w1[y]T1: Start;A Read(x);A A - 1;Write(y, A);Commit;Consistency Preservation Example31

3/24/07 Intuitively, the effect of a set of transactionsshould be the same as if they ran independently Formally, an interleaved execution oftransactions is serializable if its effect isequivalentqto a serial one. Implies a user view where the system runs eachuser’s transaction stand-alone. Of course, transactions in fact run with lots ofconcurrency, to use device parallelism.Isolation32

3/24/07 T2: Start;B Read(x);B B 1;Write(y, B);Commit;H r1[x] r2[x] w1[x] c1 w2[y] c2H is equivalent to executing T2 followed by T1Note, H is not equivalent to T1 followed by T2Also, note that T1 started before T2 and finishedbefore T2, yet the effect is that T2 ran first.T1: Start;A Read(x);A A 1;Write(x, A);Commit;A Serializability Example33

3/24/0734r1[x] r2[y] w2[y] w1[y] T2 T1 T1 T2 Serializability says the execution is equivalent tosome serial order, not necessarily to all serial ordersr1[y] r2[y] w2[y] w1[x] T1 T2 T2 T1 Client must control the relative order of transactions,using handshakes(wait for T1to commit before submitting T2). Some more serializable executions:r1[x] r2[y] w2[y] w1[x] T1 T2 T2 T1Serializability Examples (cont’d)

3/24/07 Compare to the OS view of synchronization– e.g. T1 is moving 100 from x to y.– T2 sees only half of the result of T1 r1[x] r1[y] w1[x] r2[x] r2[y] c2 w1[y] c1(inconsistent retrieval)– e.g. each transaction is trying to make x y,but the interleaved effect is a swap r1[x] r2[y] w2[x] w1[y]– e.g. T1 and T2 are each adding 100 to x r1[x] r2[x] w2[x] w1[x] (race condition)Non-Serializable Examples35

3/24/07– DB system writes all transaction updates to its log– to commit, it adds a record “commit(Ti)” to the log– when the commit record is on disk, the transaction iscommitted.– system waits for disk ack before acking to user When a transaction commits, its results willsurvive failures (e.g. of the application, OS,DB system even of the disk). Makes it possible for a transaction to be a legalcontractcontract. Implementation is usually via a logDurability36

3/24/07!1. The Basics!2. ACID Properties3 Atomicity and Two-Phase3.Two Phase Commit4. Performance5. Styles of SystemOutline37

3/24/07 Distributed systems make atomicity harder Suppose a transaction updates data managed bytwo DB systems.ycould commit the transaction,, One DB systembut a failure could prevent the other system fromcommitting. The solution is the two-phase commit protocol. Abstract “DB system” by resource manager(could be a SQL DBMS, message mgr, queuemgr, OO DBMS, etc.)381.3 Atomicity and Two-Phase Commit