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.
Session 9 Tp9
Transaction Management Session 9
<ul><li>Describe the benefits of transactions </li></ul><ul><li>Define the ACID properties </li></ul><ul><li>Differentiate between transaction models </li></ul><ul><li>Define Transaction Isolation </li></ul><ul><li>Describe the Distributed Transactions </li></ul><ul><li>List the Programmatic Transactions in EJB </li></ul><ul><li>Describe Transaction attributes </li></ul>Session Objectives
Review of Session 8 (1) <ul><li>The information determined by a bean regarding its status during runtime contains information about: </li></ul><ul><ul><li>The home object of the bean. </li></ul></ul><ul><ul><li>The transaction that involves the bean. For instance, the bean need not go through a step if the transaction being performed is going to fail. </li></ul></ul><ul><ul><li>Security to authorize the client. The bean is capable of performing this by querying its environment. It can thus ensure that the client has security access levels to perform an operation. </li></ul></ul><ul><ul><li>The various environment properties that were responsible for the deployment of the bean. </li></ul></ul><ul><li>The main objective of the context is to encapsulate the bean’s domain in a compact object. </li></ul><ul><li>The session bean context is called the session context and the entity bean context is known as the entity context . </li></ul><ul><li>When a bean has to make a call to another bean, the getEJBObject() method is used. Further, this method is also used when a reference has to be passed to a bean. </li></ul><ul><li>Authentication ensures that the identity of the client is true. The username and password are checked against a database, which contains a permanent client profile. </li></ul>
Review of Session 8 (2) <ul><li>The process of granting permissions to the correct user is called authorization. </li></ul><ul><li>When declarative authorization is performed, the container performs the validations. In such a case, the focus is entirely on business logic. </li></ul><ul><li>In programmatic authorization , security checks are coded into the bean. The bean will contain business logic along with security checks. </li></ul><ul><li>Security roles can be defined as the collection of clients. </li></ul><ul><li>The isCallerRole() method ensures that the current caller falls into the security role. The getCallerPrincipal() method gets back the current caller’s security identity. </li></ul><ul><li>Security contexts sum up the security state of the caller and perform their functions behind the scenes. </li></ul><ul><li>EJB does not have specific rules for the way containers deal with security. </li></ul><ul><li>The EJB object handle can be defined as a long-lived proxy for an EJB object. In case the client disconnects himself from the EJB server or container, the EJB object handle can be used to reconnect to get back the conversational state with the particular bean. </li></ul><ul><li>In the new EJB 2.0 specifications, the JAAS architecture makes security more portable and robust. </li></ul>
Common Problems Atomic Operations Network or Machine Failure Transaction Problems Multiple users sharing data
Atomic Operations Operation Total + + <ul><li>Operations that perform multiple, discrete tasks and yet have to execute as one contiguous, atomic operation. </li></ul><ul><li>Operation1, Operation2 and Operation3 should succeed individually for Operation Total to succeed. </li></ul><ul><li>If any one process fails, then the entire process would fail. </li></ul>Operation 1 Operation 3 Operation 2
Network or Machine Failure <ul><li>Across a multi-deployment, if a network crash occurs during a critical operation, it could lead to major implications such as loss of data. </li></ul>Network Crash Loss of data
Multiple Users Sharing Data Database <ul><li>If multiple users modify the same data simultaneously, then data could be corrupted. The database could also contain data partially supplied by one tool and partially supplied by another tool. </li></ul>
Transaction Definition <ul><li>Transaction: Series of operations that are executed as one large atomic operation. (all or none) </li></ul>Series of Operations Committed Transaction All or None
Terminologies in Transactions <ul><li>Transactional Object- An application component which is involved in transactions. It could be an enterprise bean, server component or a CORBA component. </li></ul><ul><li>Transaction Manager- Operates behind the scenes,performing all tasks. </li></ul><ul><li>Resource- A storage from which one can read and write to. </li></ul><ul><li>Resource manager- Manages the resources. </li></ul>
The ACID properties Operations in transactions Atomicity Consistency Isolation Durability
Consistency Transaction Consistency ensures that the state is consistent <ul><li>Consistency ensures that a transaction leaves the system’s state as consistent. </li></ul>
Isolation <ul><li>Isolation isolates one transaction from another. This means that multiple transactions can be read and written to a database without one transaction knowing about the other. </li></ul>
Durability <ul><li>Durability ensures that updates to managed resources survive failures. These can be machines crashing, network crashing or power failures. </li></ul>Durability Network Failure Survived Failure
Transactional Models <ul><li>Transactions can be performed through various methods. </li></ul><ul><li>There is a separate complexity and feature involved with each transactional model. </li></ul>Nested Transactions Transactional models Flat Transactions
Flat Transactions Operation 1 Operation 4 Operation 3 Operation 2 Executed as one unit of work
Nested Transactions Transaction1 Transaction2 <ul><li>Allows units of work to be embedded in other units of work. </li></ul><ul><li>When one particular unit of work nested within another unit of work performs a rollback, the entire transaction does not roll back. </li></ul><ul><li>However, only if the embedded unit gets executed, does the embedding unit get executed. </li></ul>Transaction3
Programmatic and Declarative Transactions <ul><li>A transaction ends with either a commit or an abort </li></ul><ul><li>The important questions to note are, who begins a transaction and who issues a commit or abort, and when do these steps occur. </li></ul><ul><li>This process is called demarcating transactional boundaries. </li></ul><ul><li>The two ways to demarcate transactional boundaries are: </li></ul><ul><ul><li>Programmatically </li></ul></ul><ul><ul><li>Declaratively </li></ul></ul>
Isolation Problems in EJB-I <ul><li>The Dirty Read problem: When data from an uncommitted database is read it is called the Dirty Read problem </li></ul><ul><li>The Unrepeatable Read Problem: When data is read the second time and upon reading it changes are found, it is called the unrepeatable read problem </li></ul><ul><li>The Phantom Problem: When new set of data appears in the database between two read operations, it is called the phantom problem </li></ul>
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
Distributed Transactions The Transactional Cover Application server1 Application server2 <ul><li>Distributed flat transactions allow multiple application servers to collaborate under 1 transactional cover. </li></ul>
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
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
Transactional Communications Protocol and Transaction Contexts <ul><li>The transactional context:- </li></ul><ul><li>The most important piece of information sent during the transactional communication. </li></ul><ul><li>Object that holds information about the system’s current transactional state, and can also be passed around between parties involved in transactions. </li></ul>
CORBA’s Object Transaction Service ( OTS ) CORBA’s OTS CosTransactions in terface CosTSPortability interface
CORBA’s Object Transaction Service ( OTS ) <ul><li>System-level vendors need to concentrate on the inner workings of the OTS. </li></ul><ul><li>Part of the OTS helps the developer to separate transaction boundaries programmatically. </li></ul><ul><li>OTS has been segregated into two sub APIs: </li></ul><ul><ul><li>Java Transaction Service (JTS) </li></ul></ul><ul><ul><li>Java Transaction API (JTA) </li></ul></ul>
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
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
Controlling Transactions from Client Code <ul><li>The Java Transaction API can be used in the client code to make a call to the beans. </li></ul><ul><li>JTAs can be used in case of a workflow bean, which calls several smaller beans. </li></ul><ul><li>The JTA UserTransaction interface can be looked up with the Java Naming and Directory Interface (JND I). </li></ul>
Designing Transactional Conversations in EJB Uncommitted database Aborted Transaction Rollback of the updates is performed Exception is thrown The client
Session Synchronization methods <ul><li>afterBegin(): Called after a transaction begins </li></ul><ul><li>beforeCompletion(): Called immediately before a transaction completes </li></ul><ul><li>afterCompletion(): Called directly after a transaction gets completed </li></ul>
Transaction Attributes <ul><li>Specifies how the EJB Container handles transactions for that method on client invocation through the enterprise bean’s home or component interface or when a JMS message arrives. </li></ul><ul><li>Enterprise beans have the following values for the transaction attributes: </li></ul><ul><ul><li>Required </li></ul></ul><ul><ul><li>Supports </li></ul></ul><ul><ul><li>RequiresNew </li></ul></ul><ul><ul><li>Mandatory </li></ul></ul><ul><ul><li>Never </li></ul></ul><ul><ul><li>NotSupported </li></ul></ul>
Container-Managed Transaction Demarcation for Session and Entity Beans <ul><li>NotSupported: The Container invokes the bean method whose transaction attribute is set to NotSupported with an unspecified transaction context. </li></ul><ul><li>Required: The Container must invoke a method having attribute as Required with a valid transaction context. </li></ul><ul><li>Supports: The invocation of a bean method with a transaction attribute of Supports involves two cases: </li></ul><ul><ul><li>If the client calls with a transaction context, the Container performs the same steps as described in the Required case. </li></ul></ul><ul><ul><li>If the client calls without a transaction context, the Container performs the same steps as described in the NotSupported case. </li></ul></ul><ul><li>RequiresNew: As the name suggests, the container must invoke a bean method with the attribute RequiresNew with a new transaction context. </li></ul><ul><li>Mandatory: The container has to invoke, mandatorily, a bean method with a Mandatory transaction attribute in the client’s transaction context. </li></ul><ul><li>Never: The Container invokes a bean method whose transaction attribute is set to Never without a transaction context. </li></ul>
Container-Managed Transaction for Message-Driven Beans <ul><li>The Container is responsible for transaction demarcation for the message-driven beans that the bean developer declared with transaction managed transaction demarcation. </li></ul><ul><li>Only the NotSupported and Required attributes are useful as there can be no pre-existing transaction context and no client to handle exceptions. </li></ul><ul><li>NotSupported: The context generates an unspecified transaction context while invoking a message bean’s method. If the onMessage() method invokes other enterprise beans, the container passes no transaction context with the invocation. </li></ul><ul><li>Required: The container invokes a message driven bean method with transaction attribute set to Required with a valid transaction context. </li></ul>
Summary (1) <ul><li>Transactions address three main problems: </li></ul><ul><ul><li>Atomic operations </li></ul></ul><ul><ul><li>Network or machine failure </li></ul></ul><ul><ul><li>Multiple users sharing data </li></ul></ul><ul><li>Atomic operations perform multiple discrete operations, which are collectively executed as one contiguous operation. </li></ul><ul><li>Transaction: A series of operations that are executed as one large, atomic operation. They work on the principle of ‘all or none’. </li></ul><ul><li>Multiple users can share the same data when transactions are used. They also make sure that the updated data is completely and wholly written, with no confusion about updates from other clients. </li></ul><ul><li>ACID stands for: </li></ul><ul><ul><li>Atomicity </li></ul></ul><ul><ul><li>Consistency </li></ul></ul><ul><ul><li>Isolation </li></ul></ul><ul><ul><li>Durability </li></ul></ul>
Summary (2) <ul><li>Grouping of many operations into one unit of work is known as atomicity. </li></ul><ul><li>Consistency makes sure that a transaction leaves the system’s state as consistent, once the transaction is completed. </li></ul><ul><li>The advantage of isolation is that every client feels that he/she is the only client modifying the database. </li></ul><ul><li>The two most important transactional models are: </li></ul><ul><ul><li>Flat transactions </li></ul></ul><ul><ul><li>Nested transactions </li></ul></ul><ul><li>Flat transaction is the easiest transactional model to understand. It is a series of operations performed as a single unit of work. </li></ul><ul><li>A nested transaction allows units of work to be embedded in other units of work. </li></ul>
Summary (3) <ul><li>There are two ways to demarcate transactional boundaries: </li></ul><ul><ul><li>Programmatically </li></ul></ul><ul><ul><li>Declaratively </li></ul></ul><ul><li>EJB has four transaction isolation levels: </li></ul><ul><ul><li>The TRANSACTION_READ_UNCOMMITTED mode </li></ul></ul><ul><ul><li>The TRANSACTION_READ_COMMITTED mode </li></ul></ul><ul><ul><li>The TRANSACTION_REPEATABLE_READ mode </li></ul></ul><ul><ul><li>The TRANSACTION_SERIALIZABLE mode </li></ul></ul><ul><li>The SessionSynchronization, the afterBegin (), and the beforeCompletion() methods are useful when the stateful session bean caches database data in memory while in a transaction. </li></ul>