EJB 3 Transactions - BFH · EJB 3 Transactions Course Multi Tier Business Applications with Java EE...

Berner Fachhochschule

Technik und Informatik

EJB 3 Transactions

Course Multi Tier Business Applications with Java EE

Prof. Dr. Eric DubuisBerner Fachhochschule

Biel

June 4, 2008 MTA with Java EE / Transactions 2

Content

● The problem● Transactions explained● Sample scenarios● Transactions and EJBs● Bean provider responsibilities● Transaction attributes● Explicit rollback● Transactions and stateful session bean


The Problem

● Consider two accounts, and a session bean that transfers a given amount of money from the debit account to the credit account:

b:BankBean

d:Account

c:Account


The Problem (cont'd)● The session bean has the following methods:

Problem: What happens if method deposit() fails?

@Stateless public class BankBean implements Bank {...public void transfer(String debitId, String creditId,

double amount)throws BankException {

withdraw(debitId, amount);deposit(creditId, amount);

}

public void withdraw(String accountId, double amount)throws BankException {

... }

public void deposit(String accountId, double amount)throws BankException {...

}}

if deposit() fails money was

withdrawn from the account...


Enter Transactions

● The above problem requires a one-or-nothing semantics of the operation sequence withdraw() and deposit().

Definition: Transaction

A (technical) transaction is a series of operations that appear in one large atomic operation. Transactions guarantee an all-or-nothing semantic: either all of your operations will succeed, or none of them will.

Properties of a TransactionThese properties are called the ACID properties:● A: atomicity● C: consistency● I: isolation● D: durability


Transaction Properties Explained

Atomicity PropertyThis property guarantees that a transaction bundles many operations together to appear as one contiguous unit of work. As seen from the outside, the bundle of operations appears to be one operation only.

Consistency PropertyThis property guarantees that a transaction leaves the system’s state to be consistent after a transaction completes.

Isolation PropertyThis property guarantees that incomplete results within a transaction cannot be seen by other operations.

Durability PropertyThis property guarantees that updates of managed resources survive failures. That is, if the failed component (network, remote database, etc.) is back again, the update is completed thanks to transactional logs.


Sample Scenario [EJB3-Core] (I)

● Update of Multiple Databases


Sample Scenario [EJB3-Core] (II)

● Messages Sent to a JMS Queue


Sample Scenario [EJB3-Core] (III)

● Message Received from a JMS Queue


Sample Scenario [EJB3-Core] (IV)

● Multiple EJB Servers


Sample Scenario [EJB3-Core] (V)

● Client-Managed Demarcations


Sample Scenario [EJB3-Core] (VI)

● Client-Managed Demarcations


Transaction Management

Declarative:

● transactional behavior is controlled via the @TransactionAttribute● business code has (almost no) transaction-related code

Explicit Control:

● transaction demarcation (see next) must be handled in code→ rigid, not flexible

● fairly complex API must be used→ knowledge, error-prone

● transactional code is written within business logic code→ reduces clarity of code

EJB supports

both kinds


Bean Provider Responsibility

Transaction Management and Enterprise Beans

● Container-managed transaction (CMT)● Bean-managed transaction (BMT)

Bean-Types and Transaction Management

● session beans (stateless, stateful)● message-driven beans

Transaction management cannot be specifiedfor EJB 3.0 entity beans.

Programmer has explicit control on transaction

demarcation

Container controls the transaction

demarcation

Demarcation:Start and end point for a transaction


Bean-Managed vs. Container-Managed Transactions

The developer must decide:● to demarcate transactions programmatically in the business methods

(bean-managed transaction demarcation)● or the demarcation is to be performed by the container: the default

(container-managed transaction demarcation).

Bean-managed transaction demarcation (BMT demarcations):● programmer has fine control● but transaction demarcation is hard-coded → code change if transaction

requirements change!

Container-managed transaction demarcation (CMT demarcations):● transaction attributes specified in metadata annotations● or in the deployment descriptor

For the rest of these slides we focus on CMT demarcations only.


Bean Methods and Transaction Attributes

A transaction attribute is a value associated with each of the following methods:

● a method of a bean's business interface● a message listener method of a message-driven bean● a timeout callback method● a stateless session bean's web service endpoint interface● (methods related with EJB 2.1)

We focus on methods of a bean's business interface.

Default:If no transaction attribute is specified for a method of an enterprise bean with container-managed transaction demarcation then the value of the transaction attribute for the method defaults to REQUIRED.


Transaction Attributes

These are the attributes:

● MANDATORY● REQUIRED● REQUIRES_NEW● SUPPORTS● NOT_SUPPORTED● NEVER

They are explained next.


REQUIRED Transaction Attribute

From [Burke/Monson-Haefel]


REQUIRES_NEW Transaction Attribute



MANDATORY Transaction Attribute



SUPPORTS Transaction Attribute



NOT_SUPPORTED Transaction Attribute



NEVER Transaction Attribute



Transaction Attribute Usage

● If not satisfied with the default REQUIRED, you declare the transaction attribute by using an annotation.(Alternatively, you can declare the transaction attribute in the deployment descriptor, see later.)

@Statefulpublic class BankBean implements Bank {

// ...

@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)public void transfer(String debitAccountId,

String creditAccountId, double amount)throws BankException {

...}

}

if an attribute is valid for all methods of a bean then it can be

specified on the bean class...

...and it can be

overridden when

necessary


Annotation Definition

● The definitions for @TransactionAttributeType and @TransactionAttribute are:

package javax.persistence;public enum TransactionAttributeType {

MANDATORY,REQUIRED,REQUIRES_NEW,SUPPORTS,NOT_SUPPORTED,NEVER

}

package javax.persistence;@Target({METHOD, TYPE}) @Retention(RUNTIME)

public @interface TransactionAttribute {TransactionAttributeType value() default REQUIRED;

}


Specifying Transaction Attributes with the Deployment Descriptor

● You can specify or override the transaction annotation with the help of the deployment descriptor. For example:

<ejb-jar xmlns="..." xmlns:xsi="..." xsi:schemaLocation="..." version="3.0">

... <assembly-descriptor> <container-transaction> <method> <ejb-name>BankBean</ejb-name> <method-name>*</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor></ejb-jar>

* is a wild card

denoting every

method of the bean


Variants within the Deployment Descriptor (I)

● Style 1

● Style 2

<method><ejb-name>EJBNAME</ejb-name><method-name>*</method-name>

</method>

1<method>2 <ejb-name>EJBNAME</ejb-name>3 <method-name>METHODNAME</method-name>4</method>


Variants within the Deployment Descriptor (II)

● Style 3

<method><ejb-name>EJBNAME</ejb-name><method-name>METHODNAME</method-name><method-params>

<method-param>PARAMETER_1</method-param>...<method-param>PARAMETER_N</method-param>

</method-params></method>

This variant is necessary if there

are overloaded methods


Explicit Transaction Rollback

● So-called application exceptions [EJB-Core, chapter 13] do not automatically rollback a transaction. (For a discussion of effects and consequences of exceptions see [EJB-Core, chapter 13]) To rollback a transaction explicitly you must use the setRollbackOnly() method on the bean's context object. For example:

@Stateful public class BankBeanimplements Bank, Serializable {

@Resource private SessionContext context;...@TransactionAttribute(TransactionAttributeType.REQUIRED)public void transfer(...) throws BankException {

try {...

}catch (BankException e) {

context.setRollbackOnly();throw e;

}}

... without calling this

method, the transaction is not aborted


Transactional Stateful Session Bean

● The javax.ejb.SessionSynchronization interfaces allows a session bean to receive additional notification regarding transactions. The sets of states of a stateful session bean with transactions looks like [EJB-Core]:


Miscellaneous

Further Notes● Message-driven beans may declare only NotSupported or Required.● The Mandatory attribute cannot be used with web service endpoints.

Topics Not Discussed● BMT demarcation● Rules for transaction attributes in the case of (session) bean inheritance● Transaction isolation levels● Deadlock danger with REQUIRES_NEW when navigating relationships


References

[EJB] JSR 220: Enterprise JavaBeans, Version 3.0EJB 3.0 Simplified APIhttp://jcp.org/aboutJava/communityprocess/final/jsr220/index.html

[EJB Core] JSR 220: Enterprise JavaBeans, Version 3.0EJB Core Contracts and Requirementshttp://jcp.org/aboutJava/communityprocess/final/jsr220/index.html

[EJB Persistence]JSR 220: Enterprise JavaBeansTM,Version 3.0Java Persistence APIhttp://jcp.org/aboutJava/communityprocess/final/jsr220/index.html

[Burke/Monson-Haefel]"Enterprise JavaBeans 3.0" Bill Burke and RichardMonson-Haefel, 5th edition, O'Reilly, 2006,ISBN: 0-596-00978-X.

http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html



EJB 3 Transactions - BFH · EJB 3 Transactions Course Multi Tier Business Applications with Java EE...

Documents

Transcript of EJB 3 Transactions - BFH · EJB 3 Transactions Course Multi Tier Business Applications with Java EE...