22. Isolation Problems in EJB-II The Dirty Read Problem The Phantom Problem The Unrepeatable Read Problem Transactional Isolation Problems TRANSACTION_READ_COMMITTED TRANSACTION_REPEATABLE_READ TRANSACTION_SERIALIZABLE
23.
24. Durability and Two phase Commit protocol PHASE I Before commit Message Last chance to perform abort statement Abort Yes No Transaction Continues Transaction Aborted Phase II Actual data updates are performed by resource managers RESOURCES Transactions
25. Steps in the Two-Phase Commit Statement Transaction coordinator 1. Prepare to commit statement Resource Manager 2. Message is passed to resource managers asking if they are ready to commit 3. Everyone agrees to commit Once the three steps given in the diagram are completed, the transaction coordinator asks the transaction managers to commit. This is passed on to the resource manager, which makes all resource updates permanent. Transaction Manager Transaction Manager
26.
27. CORBA’s Object Transaction Service ( OTS ) CORBA’s OTS CosTransactions in terface CosTSPortability interface
28.
29. The Java Transaction Service (JTS) Java Transactional Service Defines interfaces which are used by the transaction and resource managers Many objects are passed around and used by the transaction and resource managers
30. Java Transaction API (JTA) JTA Starts a transaction inside a bean Call other beans which are involved in a transaction Controls the commit and abort processes
31.
32. Designing Transactional Conversations in EJB Uncommitted database Aborted Transaction Rollback of the updates is performed Exception is thrown The client
33.
34.
35.
36.
37.
38.
39.
Editor's Notes
Approach: This slide is self explanatory. Details about each individual problem are addressed in subsequent slides.
Approach: Imagine that you would like to perform multiple discrete operations, yet have them execute as one contiguous, large operation. Take the classic bank account example. When you transfer money from one bank account to another, you want to withdraw funds from one account and deposit those funds to the other account. Ideally, both operations will succeed. But if an error occurs, you would like to have both operations to fail. Otherwise u will have incorrect funds in one of the accounts. You would never want one operations are part of a single atomic transaction. One simple way to handle this to perform exception handling. You could use exceptions to write a banking module to transfer funds from one account to another. But there are many problems with this approach: The code is bulky and unwieldy We need to consider every possible problem that occurs at every step of the way and code error handling routines to consider how to roll back our changes. Error handling gets out of control if we perform more complex processes than a simple withdrawal and a deposit. It is easy to imagine, for example, a 10 step process that updates several financial records. We would need to code error handling routines for each step. In the case of a problem, we need to code facilities to undo each operation. This gets very tricky and error prone to write. Testing this code is another challenge. You would have to simulate logical problems as well as failures at many different levels. Ideally, we would like a way to perform both operations in a single, large atomic operation, with a guarantee that either always succeed or both will always will always fail.
Approach: Let us extend our classic bank account example and assume our bank account logic is distributed across a multi-tier deployment. This may be necessary for security, scalability and modularization reasons. In a multi-tier deployment, any client code that wants to use our bank account must do so across the network via a remote method invocation. Distributing the application across a network introduces failure and reliability concerns. For example. What happens if the network crashes during a banking operation? Typically, an exception will be generated and thrown back to the client code-but this exception is quite ambiguous in nature. The network may have failed before money was withdrawn from an account. It is also possible that the network failed after we withdrew money. There is no way to distinguish between these two cases-all the client code sees is a network failure exception. Thus we can never know for sure how much money is in the bank account. In fact, the network may not be the only source of problems. Because we are dealing with bank account data, we are dealing with persistent information residing in a database. It is entirely feasible that the database itself could crash. The machine that the database is deployed could also crash. If a crash occurs during a database write, the database write, the database could be in in an inconsistent, corrupt state For a mission-critical enterprise application.
Approach: The above slide describes the ACID properties. Each of these are described in subsequent slides.
Approach: The slide is self explanatory. A good description of the property is given in the student guide. Every task within the transaction must execute without error. If any task fails, the entire transaction fails. If any of the tasks fails, the entire transaction is aborted, meaning that changes to the data are undone. If all the tasks execute perfectly, then the changes to the data are made durable. Let us look at an example: a TravelAgent bean. The first measure of the bean would its atomicity. Does it ensure that the transaction executes completely or not all. What we are concerned with us are the critical tasks that change or create information. Suppose there is method bookPassage(), a reservation bean is created, the ProcessPayment bean debits a credit card and a Ticket object is created. All of these tasks must be successful for the entire transaction to successful. To understand the importance of the atomic characteristic, you have to imagine what would happen if every one of the subtasks failed to execute. If for example, the creation of a Reservation failed but all other tasks succeeded, your customer will probably end up getting removed from the cruise. As far as as the travel agent is concerned, the bookPassage() method executed successfully because a Ticket was generated. If a ticket is generated without the creation of a reservation, the state of the system becomes inconsistent with reality because the customer paid for a ticket
Approach: A simple explanation of the slide is given in the student guide. Consistency is a transactional characteristic that must be enforced by both the transactional system and application developer. Consistency refers to the integrity of the underlying data store. The transactional system fulfills its obligation in consistency by ensuring that a transaction is atomic, durable and isolated. The application developer must ensure that the database has appropriate constraints(primary keys, referential integrity and so forth) and that business logic doesn’t result in inconsistent data. TravelAgent bean In order for a transaction to be consistent, the state of the business system make sense after the transaction has completed. In other words, the state of the business system must be consistent with the reality of the business. This requires that the transaction enforce the atomic, isolated and durable charcteristics of the transaction, and it also requires diligent enforcement of integrity constraints by the application developer. If for example, the application developer fails to include the credit card charge operation in the bookPassage() method, the customer would be issued a ticket but charged. The data would be inconsistent with the expectation of the business-a customer should be set up to enforce integrity constraints. For example, it should not be possible for a record to be added to the RESERVATION table unless the CABIN_ID, CRUISE_ID AND CUSTOMER_ID foreign keys map to corresponding records in the CABIN, CRUISE and CUSTOMER tables, respectively. If a CUSTOMER_ID is used that doesn’t map to a CUSTOMER record, referential integrity should cause the database to throw an error message.
Approach: The slide gives a graphic representation of isolation. A transaction must be allowed to execute without interference from other processes or transactions. In other words, the data that a transaction accesses cannot be affected by any other part of the system until the transaction is completed. TravelAgent bean If you are familiar with the concept of thread synchronization in Java or row locking schemes in relational databases, isolation will be a familiar concept. To be isolated, a transaction must protect the objects and data that is accessing from other transactions. This is necessary to prevent other transactions from interacting with data that is in transatition. In the TravelAgent bean, the transaction is isolate dto prevent other transactions from modifying the beans that are being updated. Imagine the problem that would arise if separate transactions were updated. Imagine the problems that would arise if separate transactions were allowed to change any time-transactions would walk all over each other. You could easily have several customers book the same cabin because their travel agent happened to make the their reservations at the same time The isolation of a process doesn’t mean that the entire application shuts down during a transaction. Only those entity beans and data directly affected by the transaction are isolated. In the TravelAgent bean, for example, the transaction isolates only the Reservation bean created. There can be many Reservation beans in existence; there is no reason other beans cant be accessed by other transactions.in EJB, we use isolation levels set in the deployment descriptor to determine the isolation characteristics of transactions.
Approach: This means that all the data changes made during the course of a transaction must be written to some type of physical storage before the transaction is fully completed. This ensures that changes are not lost if the system crashes.
![[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Session Objectives](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)