Chapter 2: Transaction Processing Monitors (TP-monitors) OutlineClient, server, and databasesThe nice thing about databases ...One at a time interaction2 Phase CommitInteractions through RPCTransactional RPCBasic TRPC (making calls)Basic TRPC (committing calls)One step beyond ...TP-Monitors = transactional RPCTP-Monitor functionalityTransactional propertiesTRAN-C (Encina)TP-Monitor, generic architectureTasks of a TP MonitorStructure of TP-Monitors (I)Structure of TP-Monitors (II)TP-Monitor components (generic)Example: BEA TuxedoExample: BEA TuxedoTP-Monitor components (Encina)External interfacesMonitor servicesResource managersTransaction processing componentsTP-Monitors vs. OSAdvantages of TP-MonitorsTP-Heavy vs. TP-Light = 2 tier vs. 3 tierTP-light: databases and the 2 tier approachTP-Heavy: 3-tier middlewareObject Transaction ServiceRunning a distributed transaction (1)Running a distributed transaction (2)The future of TP-MonitorsChapter 2:Transaction Processing Monitors (TP-monitors)Gustavo AlonsoComputer Science DepartmentSwiss Federal Institute of Technology (ETHZ)[email protected]://www.iks.inf.ethz.ch/©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 2Outline Historical perspective:Ä The problem: synchronization and atomic interactionÄ The solution: transactional RPC and additional support TP MonitorsÄ Example and FunctionalityÄ ArchitecturesÄ StructureÄ Components TP Monitor functionality in CORBA©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 3Client, server, and databases Processing, storing, accessing and retrieving data has always been one of the key aspects of enterprise computing. Most of this data resides in relational database management systems, which have well defined interfaces and provided very clear guarantees to the operations performed over the data. However:Ä not all the data can reside in the same databaseÄ the application is built on top of the database. The guarantees provided by the database need to be understood by the application running on topINVENTORY CONTROLIF supplies_lowTHEN BOTPlace_orderUpdate_inventoryEOTProductsdatabaseDBMSInventoryand orderdatabaseDBMSNew_productLookup_productDelete_productUpdate_productPlace_orderCancel_orderUpdate_inventoryCheck_inventoryServer 3 (inventory)Server 2 (products)©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 4The nice thing about databases ... … is that they take care of all aspects related to data management, from physical storage to concurrency control and recovery Using a database can reduce the amount of code necessary in a large application by about 40 % From a client/server perspective, the databases help in:Ä concurrency control: many servers can be connected in parallel to the same database and the database will still have correct dataÄ recovery: if a server fails in the middle of an operation, the database makes sure this does not affect the data or other servers Unfortunately, these properties are provided only to operations performed within the database. In principle, they do not apply when:Ä An operation spawns several databasesÄ the operations access data not in the database (e.g., in the server) To help with this problem, the Distributed Transaction processing Model was created by X/Open (a standard’s body). The heart of this model is the XA interface for 2 Phase Commit, which can be used to ensure that an operation spawning several databases enjoy the same atomicity properties as if it were executed in one database.©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 5One at a time interaction Databases follow a single thread execution model where a client can only have one outstanding call to one and only one server at any time. The basic idea is one call per process (thread).  Databases provide no mechanism to bundle together several requests into a single work unit The XA interface solves this problem for databases by providing an interface that supports a 2 Phase Commit protocol. However, without any further support, the client becomes the one responsible for running the protocol which is highly impractical An intermediate layer is needed to run the 2PC protocolDatabase CLIENTBOT...EOTdatabaseDBMSDBMS enforcestransactionalbracketsDatabase CLIENTBOT...EOTdatabaseDBMSAdditional layerenforcestransactionalbracketsdatabaseDBMS2 Phase Commit coordinatorXA XA©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 62 Phase CommitBASIC 2PC Coordinator send PREPARE to all participants. Upon receiving a PREPARE message, a participant sends a message with YES or NO (if the vote is NO, the participant aborts the transaction and stops). Coordinator collects all votes:Ä All YES = Commit and send COMMIT to all others.Ä Some NO = Abort and send ABORT to all which voted YES. A participant receiving COMMIT or ABORT messages from the coordinator decides accordingly and stops.What is needed to run 2PC? Control of Participants: A transaction may involve many resource managers, somebody has to keep track of which ones have participated in the execution Preserving Transactional Context: During a transaction, a participant may be invoked several times on behalf of the same transaction. The resource manager must keep track of calls and be able to identify which ones belong to the same transaction by using a transaction identifier in all invocations Transactional Protocols: somebody acting as the coordinator in the 2PC protocol Make sure the participants understand the protocol (this is what the XA interface is for)©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 7Interactions through RPC RPC has the same limitations as a database: it was designed for one at a time interactions between two end points. In practice, this is not enough:a) the call is executed but the response does not arrive or the client fails. When the client recovers, it has no way of knowing what happenedb) c) it is not possible to join two calls into a single unit (neither the client nor the server can do this)databaseDBMSclientserver(a)databaseDBMSclientserver(b)databaseDBMSdatabaseDBMSclientserver(c)databaseDBMSserver©Gustavo