Plan. Department of Informatics. Advanced Software Engineering Prof. J. Pasquier-Rocha Cours de Master en Informatique - SH 2003/04

Transcription

1 Plan 1. Application Servers 2. Servlets, JSP, JDBC 3. J2EE: Vue d ensemble 4. Distributed Programming 5. Enterprise JavaBeans 6. Enterprise JavaBeans: Transactions 7. Prise de recul critique

2 Enterprise JavaBeans: Transactions 1. Motivation 2. Benefits of transactions (ACID) 3. Transactional models 4. Transaction styles 5. Container-Managed Transactions 6. Other issues

3 6.1 Motivation Atomic Operations Perform multiple discrete operations having them executed as one contiguous, large, atomic operation. Example: transfer money from one account to another. Two discrete operations: Withdraw fund from one account Deposit those funds into the other account We would like a way to perform both operations in a single, large, atomic operation, with a guarantee that both operations either always succeed, or both always fail.

4 6.1 Motivation Network or Machine Failure Distributing applications across the network introduces failure and reliability concerns. If the network crashes during our banking operation, an exception is thrown back to the client, but there is no way to know if it has failed before or after money has been withdrawn from an account. The network may not be the only source of problems: databases can crash or machines the databases are deployed on can also crash. If a crash occurs during a database write, the database could be in an inconsistent, corrupted state. There needs to be a recovery process to handle these crashes.

5 6.1 Motivation Multiple Users Sharing Data Several application servers may share the same database and could potentially be modifying the same set of data records within the database. If two users modify the same data simultaneously, their operation may become interleaved. Therefore, the database may contain data partially supplied by one user and partially supplied by another user. This is essentially corrupted data. There needs to be a mechanism to deal with multiple users concurrently modifying data. We must guarantee data integrity even when many users concurrently update the data.

6 6.2 Benefits of Transactions (ACID) Benefits of Transactions (ACID) One can avoid the problems just raised by properly using transactions. When you properly use transactions, your operations will always execute with a suite of four guarantees; the well known ACID properties of transactions: A tomicity C onsistency I solation D urability

7 6.2 Benefits of Transactions (ACID) Atomicity To be atomic, a transaction must execute completely or not at all. Every task within a unit-of-work must execute without error. Atomicity guarantees that operations performed within a transaction undergo an all-ornothing paradigm: If any of the tasks fails, the entire unit-of-work or transaction is aborted, meaning that any changes to the data are undone. (~ a robust way of performing error handling) If all the tasks execute successfully, the transaction is committed, which means that changes to the data are made permanent or durable.

8 6.2 Benefits of Transactions (ACID) Consistency Consistency refers to the integrity of the underlying data store. Consistency is a transactional characteristic that must be enforced by both the transactional system (ensures atomicity, isolation and durability) AND the application developer (ensures that the system is in a consistent state). Consistent state is defined by an invariant set of rules / constraints (in an account transfer, for example, a debit to one account must equal the credit to another account). During the course of a transaction they may be violated resulting in a temporary inconsistent state. But when the transaction completes, the state must be consistent again.

9 6.2 Benefits of Transactions (ACID) 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 or unit-ofwork is completed. The transaction system achieves isolation by using low-level synchronization protocols (holding locks ) on the underlying database data.

10 6.2 Benefits of Transactions (ACID) Durability Durability guarantees that updates to managed resources, such as database records, survive failures (machine crashing, networks crashing, hard disks crashing, power failures, ). 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 successfully completed.

11 6.3 Transactional Models Transactional Models Transactional Models: there are different models for performing transactions. Each model adds its own complexity and features to your transactions. The two most popular models are flat transactions and nested transactions. Remark: Enterprise JavaBeans does not support nested transactions and mandates flat transactions. But, this may change in the future based on industry demands.

12 6.3 Transactional Models Flat Transactions A flat transaction is a series of operations that are performed atomically as a single unit of work. A transaction might abort for many reasons. Many components can be involved in a transaction, and any component could suffer a problem that would cause an abort. These problems include the following: Invalid parameters passed to one of the components. An invariant system state was violated. Hardware or software failure.

13 6.3 Transactional Models Flat Transactions (2)

14 6.3 Transactional Models How Transactional State is Rolled Back When an abort occurs the transactional state is rolled back. Your component performs some persistent operations, such as database updates. But when this happens, your database s resource manager does not permanently apply the updates to the database: your persistent operations are not yet durable and permanent. The resource manager waits until a commit statement has been issued. Your business components typically do not perform any rollback of permanent state; if there is an abort, the resource (such as a database) does not make your database updates permanent. Your components don t have any undo logic for permanent data inside of them; rather the underlying system does it for you behind the scenes. Thus, when your business components perform operations under a transaction, each component should perform all persistent operations assuming that the transaction will complete properly.

15 6.3 Transactional Models Nested Transactions A nested transaction allows you to embed atomic unit of work within other units of work. The unit of work that is nested within another unit of work can roll back without forcing the entire transaction to roll back. Therefore the larger unit can attempt to retry the embedded unit of work. If the embedded unit can be made to succeed, the larger unit can succeed. If the embedded unit of work cannot be made to work, it will ultimately force the entire unit to fail. In nested transactions, subtransactions can independently roll back without affecting higher transactions in the tree.

16 6.3 Transactional Models Nested Transactions (2) Image tirée du livre Mastering Enterprise JavaBeans, Ed Roman, Wiley

17 6.4 Transaction Styles Transaction styles In EJB your code never gets directly involved with the low level transaction system. But demarcating transactional boundaries is necessary: Who begins a transaction, who issues either a commit or abort, and when each of these steps occur. There are three ways to demarcate transactions: programmatically, declaratively, or client-initiated.

18 6.4 Transaction Styles Programmatic Transactions Figure from the book Mastering Enterprise JavaBeans, Ed Roman, Wiley You are responsible for programming transaction logic into your application code. That is you are responsible for issuing a begin statement and either a commit or an abort statement.

19 6.4 Transaction Styles Declarative Transactions Figure from the book Mastering Enterprise JavaBeans, Ed Roman, Wiley Declarative transactions allow for components to automatically be enlisted in transactions. That is, your enterprise beans never explicitly issue a begin, commit or abort statement. The EJB container performs it for you.

20 6.4 Transaction Styles Declarative Transactions (2) EJB declarative transactions add huge value to your deployments because your beans may not need to interact with any transaction API. In essence, your bean code and your client are not even really aware of transactions happening around them. EJB allows you to specify how your enterprise bean is enrolled in a transaction through the deployment descriptor, as follows (not for Entity Beans): Declarative: <transaction-type>container</transaction-type> Programmatic: <transaction-type>bean</transaction-type>

21 6.4 Transaction Styles Client-Initiated Transactions Figure from the book Mastering Enterprise JavaBeans, Ed Roman, Wiley The final way to perform transactions is to write code to start and end the transaction from the client code outside of your bean.

22 6.4 Transaction Styles Choosing a transaction style The benefit of programmatic transactions is that your bean has full control over transactional boundaries. Allows for minitransactions within a bean method, in comparison with declarative or client-initiated transactions, your entire method must either run under a transaction or not. The benefit of declarative transactions is that they are simpler. No transactional logic to write into your bean class: saves coding time and allows you to tune transactions without having access to source code. Client-controlled transactions are helpful when using remote clients (if a RemoteException occurs you can abort the transaction). Bean-managed, i.e. programmatic, transactions are illegal for entity beans. Entity beans must use declarative transactions.

23 6.5 Container-Manager Transactions Container-Managed Transactions A transaction attribute is a setting that you give to a bean to control how your bean is enlisted in container-managed transactions. The transactional attribute is a required part of each bean's deployment descriptor. Note that you can specify transaction attributes for entire beans or for individual bean methods. You must specify transaction attributes on all business methods for your beans. Furthermore, with entity beans you must specify transaction attributes that cover the home interface methods, because the home interface creation methods insert database data and thus need to be transactional. Every enterprise bean must have a transactional attribute setting. 6 values are possible for the transaction attribute in the deployment descriptor.

24 6.5 Container-Manager Transactions Container-Managed Transactions (2) Declaring transaction attributes in the deployment descriptor: <ejb-jar>... <assembly-descriptor>... <container-transaction> <method> <ejb-name>employee</ejb-name> <method-name>*</method-name> </method> <transaction-attribute>required</transaction-attribute> </container-transaction> <container-transaction> <method> <ejb-name>employee</ejb-name> <method-name>setname</method-name> </method> <transaction-attribute>supports</transaction-attribute> </container-transaction>... </assembly-descriptor>... </ejb-jar>

25 6.5 Container-Manager Transactions EJB Transaction Attribute Values (1) Required Figure from the book Enterprise JavaBeans, R. Monson-Haefel, O'Reilly Runs in client s context if it exists, otherwise Container creates a new context. Used for a method that requires transaction, but can participate in a broader unit of work. Example: depositing money in an account Can be atomic by itself or part of a greater transaction involving other operations

26 6.5 Container-Manager Transactions EJB Transaction Attribute Values (2) Figure from the book Enterprise JavaBeans, R. Monson-Haefel, O'Reilly RequiresNew Container always runs the method in a new transaction. Useful for work that commits regardless of results of outer unit of work. The bean has ACID properties, but runs as a single unit of work without allowing external logic to also run in the transaction.

27 6.5 Container-Manager Transactions EJB Transaction Attribute Values (3) Figure from the book Enterprise JavaBeans, R. Monson-Haefel, O'Reilly Supports Uses client s context if it exists otherwise runs without a context. Needs to be used with caution.

28 6.5 Container-Manager Transactions EJB Transaction Attribute Values (4) Figure from the book Enterprise JavaBeans, R. Monson-Haefel, O'Reilly Mandatory Client must invoke the method from within a transaction. Container uses this context but will not automatically start a transaction. It is then resumed when the client regained control.

29 6.5 Container-Manager Transactions EJB Transaction Attribute Values (5) Figure from the book Enterprise JavaBeans, R. Monson-Haefel, O'Reilly NotSupported Method never called within a transaction. Container suspends client context if exists.

30 6.5 Container-Manager Transactions EJB Transaction Attribute Values (6) Figure from the book Enterprise JavaBeans, R. Monson-Haefel, O'Reilly Never Client must not invoke the method from within a transaction. Container does not provide transaction context.

31 6.5 Container-Manager Transactions Transaction Attribute Summary Transaction Attribute Required RequiresNew T1 none T1 Client's Transaction none T2 T1 T2 T2 Bean's Transaction Summary of the effects of each transaction attribute. T1 is a transaction passed with the client request, and T2 is a secondary transaction initiated by the container. Supports Mandatory NotSupported none T1 none T1 none none T1 error T1 none This is important because you can use this information to control the length of your transaction. T1 none Never none none T1 error Table from the book Mastering Enterprise JavaBeans, Ed Roman, Wiley

32 6.5 Container-Manager Transactions Transaction Attribute Summary (2) Transaction Attribute Stateless Session Bean Stateful Session Bean Implementing Session Synchronization Entity Bean Message-Driven Bean Required Yes Yes Yes Yes RequiresNew Yes Yes Yes No Mandatory Yes Yes Yes No Supports Yes No No No NotSupported Yes No No Yes Never Yes No No No Table from the book Mastering Enterprise JavaBeans, Ed Roman, Wiley Entity beans and stateful session beans with SessionSynchronization must use transactions: both are transactional in nature. Therefore you can't use following attributes: Never, NotSupported, Supports. A client does not call a message-driven bean directly; rather, message-driven beans read messages off a message queue in transactions separate from the client's transaction. There is no client, and therefore transaction attributes that deal with the notion of a client's transaction make no sense for message-driven beans-namely Never, Supports, RequiresNew and Mandatory.

33 Declarative vs. Progammatic Transactions Declarative or container-managed public void deposit(double amnt) throws AccountException { balance += amnt; } Deployment descriptor: <assembly-descriptor>... <container-transaction> <method> <ejb-name>account</ejb-name> <method-name>deposit</method-name> <method-param>double</method-param> </method> <trans-attribute>required<trans-attribute> <container-transaction>... </assembly-descriptor> 6. Enterprise JavaBeans: Transactions 6.5 Container-Manager Transactions

34 6.5 Container-Manager Transactions Declarative vs. Progammatic Transactions (2) Programmatic or bean-managed (using JTA): public void deposit(double amnt) throws AccountException { Context ctx = new InitialContext(); javax.transaction.usertransaction usertran = null; try { usertran = ctx.getusertransaction(); usertran.begin(); balance += amnt; usertran.commit(); } catch (Exception e) { if (usertran!= null) usertran.rollback(); throw new AccountException("Deposit failed because of " + e.tostring); } } Deployment descriptor: <enterprise-beans> <session> <ejb-name>account</ejb-name>... <transaction-type>bean</transaction-type>... <session> </enterprise-beans>

35 6.6 Other Issues Other Issues Message-driven beans Transaction Isolation and Locking READ UNCOMITTED mode READ COMITTED mode REPEATED READ mode SERIALIZABLE mode Distributed Transactions with multiple application servers and/or multiple databases. Designing Transactional Conversations in EJB Container-managed transactions with stateful session beans: need to implement the SessionSyncronization interface. This allows for not loosing a whole conversational state if a transaction does not commit at the first attempt.