EJB Container services Presentation by Arun Kalluri 04 02 2001 Introduction EJB container provides support for transaction security communications and Exception handling Implementation differs between EJB containers Allows to deploy the applications using only the tools provided by server vendor The topics covered are Transaction Security Exception handling Communication Transactions 1 2 3 4 Definition A set of operations that must be processed as a single unit CharacteristicsAtomic operations in a set must succeed or fail Consistent Data base must be left in a state that does not compromise a business logic regardless of the success or failure of a transaction Isolated Business logic an proceed without consideration for other activities of the system Durable once the transaction has been succeeded the results will be reflected in a persistent store A transaction has a discrete starting point and ending point Transactions come at a cost in performance and scalability Containers cannot manage the transactions for some beans The EJB programmer can choose any of the following Bean managed transaction demarcation use a simple API to demarcate transaction boundaries Container managed transaction demarcation provide information in the XML deployment descriptor The developer of session bean must declare the type of transaction in XML deployment descriptor transaction type Bean transaction type transaction type Container transaction type Declarative semantics NotSupported Operates in an unspecified transaction context Gives EJB container wide latitude to access resources If a method with NoSupported transactional attribute is called by another method with some specific transactional context then the EJB container will suspend the transaction of the second method Supports Container acts the same as if the transactional attribute is required or NotSupported if the method is called by a client with valid transaction context or without an existing transaction context RequiresNew The container will suspend the existing transaction and start new one if the method is called with an existing transaction context If no transaction context then new transaction is created and commits it when method returns Required The Container will always invoke this method with valid transaction context If a client has a transaction context then that is passed by container otherwise it will create a new one Mandatory If method called is called with an existing transaction context the container will use it If the method is called without a valid existing transaction context container throws exception java transaction TransactionRequiredException Never If method is called with transaction context the container throws an exception java rmi RemoteException If a method is called with no transactional context the container acts as if the transactional attribute is NotSupported Specifying Transactional Attributes The transactional attributes of a method are declared in a XML deployment descriptor Deployment descriptor uses containertransaction Each transaction element has two child elements method transactional attribute Three ways to specify a method element Example 1 container transaction method ejb name Product ejb name method name method name method trans attribute Required trans attribute container transaction Example 2 container transaction method ejb name Product ejb name method name getname method name method trans attribute Required trans attribute container transaction Example 3 container transaction method ejb name Product ejb name method name getTaxes method name method params method param java lang string method param method param int method param method params method trans attribute Required trans attribute container transaction Choosing transactional attributes If you have a method that modifies a data in a relational database best attribute is required If you want to access a data in context of other operation that modified the data then support attribute is preferred If the resource the bean uses does not support external transaction coordinator NotSupported is preferred for all methods An entity bean s persistence callback methods ejbload and ejbstore are called with same transactional attributes of the business method that triggered these methods Ejbstore method is guaranteed to be called before on the transaction s commit boundary EJB container s management of state caching works only if the business methods work in a transaction Two minimum guarantees Container calls ejbload atleast once between the time the ejb is associated with an object identity and the time the business method is called Container calls the ejbstore atleast once between the time the method is called and the time the ejb is disassociated with the object identity User controlled Transactions begin the client starts the transaction commit the transaction can be completed successfully rollback transaction can be completed unsuccessfully getstatus checks if the transaction is rolled back Disadvantages of user controlled transaction Client is taking the responsibility Changes should be made to java code instead of XML file Isolation levels Keeping the transaction isolated from effects of other transaction on the same data Managing Isolation levels APIs is resource specific and not EJB EJBs that manage their own resources can specify the isolation levels programmatically JDBC provides two methods in java sql connection void setTransactionIsolation int level int getTransactionIsolation Accesses to a resource within a single transaction should have same isolation level Java sql Connection interface operates four predefined isolation levels These isolation levels are integer constants defined in connection class Isolation levels deal with three well defined problems dirty reads nonrepeatable reads and phantom reads The three problems in increasing difficulty are Dirty read allows a row changed by one transaction to be read by another transaction before any changes in the row take places Non repeatable read one transaction reads the row the other transaction alters or deletes the row and first transaction re reads the row getting different values Phantom read one transaction reads all rows that satisfy a condition a second transaction inserts a row that satisfies the condition and the first transaction rereads the row TRANSACTION READ UNCOMMITED Prevents none of the problems TRANSACTION READ COMMITED Prevents dirty read TRANSACTIONAL