EJB3 Advance Features

Cranking up advance features of EJB

EJB3 beans are managed objects.
The EJB container makes beans “special” by acting as
a proxy between the client and the actual bean
instance.
The container provides EJB services to the client on
behalf of the bean instance.
For each bean instance, the container automatically
generates a proxy called an EJB object.
The EJB object has access to all the functionality of
the container such as JNDI registry, security,
transaction management, thread pools, session
management.
The EJB object is aware of the bean configuration and
what services the POJO is supposed to provide.

The EJB object can “insert” container services
to client requests as needed, including
managing all aspects of the bean lifecycle.
All the service details are completely
transparent to the bean clients.
The client interacts with the EJB object
through the business interface for session
beans.
The EJB object or message endpoint sits
between the message provider and the bean
instance for MDBs.

Ideally, EJB components should merely
hold business logic and never access the
container or use container services
directly.
All the services are overlaid on the bean
through configuration.
The EJBContext interface allows direct
programmatic access to services such as
transaction and security, which are
typically specified through configuration
and completely managed by the container.

public interface EJBContext {
public Principal getCallerPrincipal();
public boolean isCallerInRole(String roleName);
public EJBHome getEJBHome();
public EJBLocalHome getEJBLocalHome();
public boolean getRollbackOnly();
public UserTransaction getUserTransaction();
public void setRollbackOnly();
public TimerService getTimerService();
public Object lookup(String name);
}

Methods Description
getCallerPrincipal
isCallerInRole
These methods are useful when using in bean-managed
security.
getEJBHome
getEJBLocalHome
These methods are used to obtain the bean’s
“remote home” and “local home” interfaces.
getRollbackOnly,
setRollbackOnly
These methods are used for EJB transaction
management in the case of container-managed
transactions.
getUserTransaction This method is used for EJB transaction management
in the case of bean-managed transactions
getTimerService This method is used to get access to the EJB timer
service.
lookup This method is used to get references to objects stored
in the JNDI registry

The session bean–specific subclass is
javax.ejb.SessionContext, and the MDB-specific
subclass is javax.ejb.MessageDrivenContext.

EJBContext can be accessed through DI.
The SessionContext adds a number of methods specific to the
session bean environment.
The getEJBLocalObject and getEJBObject methods are meant for
EJB 2 beans and will generate exceptions if used with EJB 3
beans.
MessageDrivenContext adds no methods specific to MDB and
throws exceptions if the isCallerInRole, getEJBHome, or
getEJBLocalHome methods are called.
It is illegal to inject a MessageDrivenContext into a session bean
or a SessionContext into an MDB.
@MessageDriven
public class OrderBillingMDB {
@Resource MessageDrivenContext context; }

The container uses the explicitly specified name
parameter to figure out what resource to inject.
The value of the name parameter in @Resource (or
res-ref-name) is translated to a fully qualified JNDI
mapping in the form java:comp/env/[value of the
name parameter].
If the name element in the @Resource annotation is
not specified, the JNDI name for the resource will be of
the form java:comp/env/ [bean class name including
package]/[name of the annotated field/property].
EJB 3 essentially assumes that all JNDI names used in
code are local references instead of global JNDI names
and automatically prepends names with the
java:comp/env/ prefix.

Many application servers automatically resolve the
environment naming context name to the global JNDI name
if a resource with the same global JNDI name exists.
Application servers allow you to explicitly specify a global
JNDI name using the mappedName parameter of the
@Resource annotation.
@Resource(name="jdbc/ActionBazaarDS",
mappedName="java:/DefaultDS")
private javax.jdbc.DataSource myDB;
Using the mappedName parameter makes code less
portable, hence use of deployment descriptors for mapping
global JNDI names is preferred instead.
The container resolves the JNDI references to the resources
and binds the resource to the ENC during deployment.

The @Resource annotation can also be applied to setter
methods, and even classes along with instance variables.
The setter injection relies on JavaBeans property-naming
conventions, with instance variables being private and, getters
and setter non-private.
@Stateless
public class PlaceBidBean implements PlaceBid {
private DataSource dataSource;
@Resource(name="jdbc/actionBazaarDB")
public void setDataSource(DataSource dataSource) {
this.dataSource = dataSource;
}

The optional type parameter of the @Resource
annotation can be used to explicitly set the type of
the injected resource.
If omitted, the type of the injected resource is
assumed to be the same as the type of the instance
variable or property.
The type element is mandatory when the @Resource
annotation is used at the class level and uses JNDI to
obtain a reference to the resource
@Resource(name="jdbc/actionBazaarDB",
type=javax.sql.DataSource.class)
private DataSource dataSource;

DI is supported only in the managed classes and cannot be
used for injection in helper or utility classes.
In the helper classes, the resource is look up using JNDI.
1) Reference resource in EJB class:
@Resource(name="jdbc/actionBazaarDB",mappedName="jdbc
/actionBazaarDS", type=javax.sql.DataSource.class)
@Stateless
public class PlaceBidBean implements PlaceBid
2) Look up the resource either from the EJB or the helper class:
Context ctx = new InitialContext();
DataSource ds = (DataSource)
ctx.lookup("java:comp/env/jdbc/ActionBazaarDB")

Parameter Type Description Default
authentication
-Type
enum
Authentication-
Type {CONTAINER,
APPLICATION}
The type of authentication
required for accessing the
resource. The CONTAINER value
means that the container’s security
context is used for the resource.
The APPLICATION value means
that authentication for the
resource must be provided by the
application.
CONTAINER
shareable boolean Specifies whether the resource can
be shared.
true
description String The description of the resource. ""
mappedName String A vendor-specific name that the
resource may be mapped to, as
opposed to the JNDI name.
""

The EJB context instance variable to be
injected is not stored in JNDI.
When the container detects the
@Resource annotation on the context
variable, it figures out that the EJB
context specific to the current bean
instance must be injected by looking at
the variable data type,
javax.ejb.SessionContext or parent data
type, javax.ejb.EJBContext.

Environment entries are essentially meant to be robust
application constants and support a relatively small range of data
types.
Environment entries are specified in the deployment descriptor
and are accessible via JNDI.
<env-entry>
<env-entry-name>censorship</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>true</env-entry-value>
</env-entry>
Since environment entries are accessible via JNDI they can be
injected by name.
The data types of the environment entry and the injected variable
must be compatible.
@Resource(name="censorship") private boolean censorship;

JavaMail Sessions abstract the e-mail server configuration and
can be stored in the application server JNDI registry.
The Session can be injected into an EJB (with the @Resource
annotation and name parameter specifying JNDI name).
The container-managed timer service gives EJBs the ability to
schedule tasks.
The timer service is not saved in JNDI, but the container
resolves the resource by looking at the data type of the
injection target.
The one DI feature glaringly missing is the ability to inject
resources into POJOs and to inject POJOs that are not EJBs.
An EJB bean class may inherit from another EJB class or a POJO.
If the superclass defines any dependencies on resources using
the @Resource annotation, they are inherited by the subclass.

There are two ways of using programmatic lookups—using either the
EJB context or a JNDI initial context.
Any object stored in JNDI using the EJBContext.lookup method
(including session bean references).
Lookups compared to DI allows to determine which resource to use
dynamically at runtime instead of being constrained to using static
configuration.
DI and lookup using the EJB context are only available inside the Java
EE container.
Basic method of looking up JNDI outside a container:
Context context = new InitialContext();
BidderAccountCreator accountCreator
= (BidderAccountCreator)
context.lookup("java:comp/env/ejb/BidderAccountCreator");
accountCreator.addLoginInfo(loginInfo);
accountCreator.createAccount();

@EJB(name="ejb/BidderAccountCreator",
beanInterface =
BidderAccountCreator.class)
@Stateless
public class GoldBidderManagerBean implements
GoldBidderManager {
@Resource SessionContext sessionContext;
BidderAccountCreator accountCreator =
(BidderAccountCreator)
sessionContext.lookup("ejb/BidderAccountCreator");
accountCreator.addLoginInfo(loginInfo);
accountCreator.createAccount();

EJB 3 interceptors are triggered at the beginning of a method and are
around when the method returns;
They can inspect the method return value or any exceptions thrown by the
method.
Interceptors can be applied to both session and message-driven beans.
@Stateless
@Interceptors(ActionBazaarLogger.class)
public void addBid(Bid bid) { }
}
public class ActionBazaarLogger {
@AroundInvoke
public Object logMethodEntry(
InvocationContext invocationContext) throws Exception {
System.out.println(invocationContext.getMethod().getName());
return invocationContext.proceed(); }
}

The @Interceptors annotation allows you to specify
one or more interceptor classes for a method or class.
When the @Interceptors annotation is applied to an
entire class, the interceptor is triggered if any of the
target class’s methods are invoked.
The @Interceptors annotation allows to attach more
than one interceptor either at a class or method level
by using a comma-separated list as a parameter to the
annotation.
@Interceptors({ActionBazaarLogger.class,
BidStatisticsTracker.class})
public class PlaceBidBean { ... }

A default interceptor is essentially a catchall mechanism that
attaches to all the methods of every bean in the EJB module.
The interceptors are called from the larger scope to the smaller
scope with the default interceptor triggered first, then the
class-level interceptor, and finally the method level interceptor.
<assembly-descriptor>
<interceptor-binding>
<ejb-name>*</ejb-name>
<interceptor-class>
actionbazaar.buslogic.ActionBazaarLogger
</interceptor-class>
</interceptor-binding>
</assembly-descriptor>

If more than one interceptor is applied at any given level,
they are executed in the order in which they are specified.
Applying the @javax.interceptor.Exclude-
DefaultInterceptors annotation on either a class or a method
disables all default interceptors on the class or method.
Similarly the @javax.interceptor.Exclude- ClassInterceptors
annotation disables class-level interceptors for a method.
@Interceptors(ActionBazaarLogger.class)
@ExcludeDefaultInterceptors
@ExcludeClassInterceptors
public void addBid (...

Interceptor must always have only one method that is designated
as the around invoke (AroundInvoke) method.
Around invoke methods must not be business methods.
An around invoke method (with @AroundInvoke annotation) is
automatically triggered by the container when a client invokes a
method that has designated it to be its interceptor.
Any method designated AroundInvoke must follow the pattern:
Object <METHOD>(InvocationContext) throws Exception
The call to proceed method of InvocationContext interface tells
the container that it should proceed to the next interceptor in the
execution chain or call the intercepted business method.
If a business method interceptor throws an exception before
invoking the proceed method, the processing of other
interceptors in the invocation chain and the target business
method will be terminated.

public interface InvocationContext {
public Object getTarget();
public Method getMethod();
public Object[] getParameters();
public void setParameters(Object[]);
public java.util.Map<String,Object> getContextData();
public Object proceed() throws Exception;
}
The getTarget method retrieves the bean instance that the intercepted method
belongs to.
The getMethod method returns the method of the bean class for which the
interceptor was invoked.
The getParameters method returns the parameters passed to the intercepted method
as an array of objects.
The setParameters method allows us to change these values at runtime before they
are passed to the method.
The InvocationContext.getContextData method enables to access the contexts that are
shared across the interceptor chain for a given method, inorder to communicate
between interceptors using the data attached to an InvocationContext.
The invocation context data is simply a Map used to store namevalue pairs.

Lifecycle callbacks defined in an interceptor class are known
as lifecycle callback interceptors or lifecycle callback
listeners.
When the target bean transitions lifecycles, annotated
methods (@PostConstruct, @PrePassivate, @PostActivate,
and @PreDestroy) in the interceptor class are triggered.
Lifecycle interceptor methods cannot throw checked
exceptions.
A bean can have the same lifecycle callbacks both in the
bean itself as well as in one or more interceptors.
The InvocationContext proceed method in lifecycle
interceptor methods ensures that the next lifecycle
interceptor method in the invocation chain or the bean
lifecycle method is triggered.

Feature Lifecycle Callback Business Method
Invocation Gets invoked when a lifecycle
event occurs.
Gets invoked when a business method
is called by a client.
Location In a separate Interceptor class or
in the bean class
In the class or an interceptor class.
Method
signature
void<METHOD>(InvocationConte
xt) in a separate interceptor class.
void <METHOD>()–in bean class.
Object <METHOD>(Invocation-
Context) throws Exception
Annotation @PreDestroy, @PostConstruct,
@PrePassivate, @PostActivate
@AroundInvoke
Exception
handling
May throw runtime exceptions but
must not throw checked
exceptions. May catch and swallow
exceptions. No other lifecycle
callback methods are called if an
exception is thrown.
May throw application or runtime
exception. May catch and swallow
runtime exceptions. No other business
interceptor methods or the business
method itself are called if an exception is
thrown before calling proceed method.
Transaction
& security
context
No security and transaction
context.
Share same security & transaction
context within which the original
business method was invoked.

The EJB 3 timer service allows to specify a method
(called the timeout method) that is automatically
invoked by the container after a specified interval of
time.
The timer service can be used to register for callbacks
triggered once at a specific time or at regular intervals.
Timers can only be used in stateless session beans and
MDBs because of their asynchronous, stateless nature.
Timers are persistent and can survive a container crash
or restart.
Timers are transactional, that is, a transaction failure in
a timeout method rolls back the actions taken by the
timer.

...
@Resource TimerService timerService;
...
public void addBid(Bid bid) {
... Code to add the bid ...
timerService.createTimer(15*60*1000, 15*60*1000, bid);
...
}
...
@Timeout
public void monitorBid(Timer timer) {
Bid bid = (Bid) timer.getInfo();
... Code to monitor the bid ...
}
}

The EJB timer service can be injected into
a Java EE component using the @Resource
annotation.
The EJB container timer service can also be
accessed through the EJB context.
@Resource SessionContext context;
TimerService timerService =
context.getTimerService();

public interface javax.ejb.TimerService {
public Timer createTimer(long duration,
java.io.Serializable info);
public Timer createTimer(long initialDuration, long
intervalDuration, java.io.Serializable info);
public Timer createTimer(java.util.Date expiration,
public Timer createTimer(java.util.Date
initialExpiration, long intervalDuration,
public Collection getTimers();
}

The first createTimer method allows to create a single-event
timer that is fired only once and not repeated.
The first parameter, duration, specifies the time in milliseconds
after which the method should be invoked.
The second parameter, info, allows to attach an arbitrary piece
of information to the timer, and must be always Serializable.
The second createTimer method allows to create recurring
timers with initial timeout and interval durations set in
milliseconds.
The third version allows to create a timer that fires once and
only once with value of expiration time as a specific instant in
time represented by a java.util.Date instead of a long time
offset.
The fourth version is similar to second version of the
createTimer method, using a concrete date instead of an offset
from the current time.
The getTimers method retrieves all of the active Timers
associated with the current EJB.

The @Timeout annotation is used to specify the designated
timeout method.
the @Timeout annotation has convention as:
void <METHOD>(Timer timer)
A bean can have at most one timeout method, which can be
specified (through annotation @Timeout or deployment
descriptor timeout-method) either on the bean class or on a
superclass.
If the bean class implements the javax.ejb.TimedObject
interface, the ejbTimeout method is the bean’s timeout
method.
The Timer for which the callback was invoked is passed in as a
parameter for the method as processing context because
multiple Timers may invoke the same timeout method.

public interface javax.ejb.Timer {
public void cancel();
public long getTimeRemaining();
public java.util.Date getNextTimeout();
public javax.ejb.TimerHandle getHandle();
public java.io.Serializable getInfo();
}

The cancel method is useful in canceling a timer prior to
its expiration.
The getTimeRemaining method is used on either a single-
use or interval timer and returns the remaining time for
the timer to expire, in milliseconds.
The getNextTimeout method indicates the next time a
recurring Timer will time out, as a java.util.Date instead of
a long time offset.
The getHandle method returns a javax.ejb.TimerHandle,
which is a serialized object to store and to obtain
information about the Timer.
The getInfo method is useful in writing nontrivial timeout
functions and accessing extra processing information
attached to the Timer by the bean method creating the
Timer.

EJB Timers are transactional objects and on an
runtime exception in the timeout method, the timer
creation is undone.
The timeout method can be executed in a
transactional context.
A transactional attribute can be specified for the
timeout method—Required or RequiresNew—and the
container will start a transaction before invoking the
timeout method.
If the transaction fails, the container will make sure
the changes made by the failed method do not take
effect and will retry the timeout method.

Timers are part of the EJB specification and portable across
containers.
EJB timer service comes as a standard part of a Java EE application
server involving no extra cost and config.
The timer is a container-managed service and hence likely to have
better out-of-the-box performance.
Transactions are fully supported with timers.
By default, EJB timers are persisted and survive EJB lifecycles and
container restarts.
EJB timers are not meant for realtime applications where precision
timing is absolutely critical.
EJB timers lack support for extremely flexible cron-type timers,
blackout dates, workflow modeling for jobs etc.
There is no robust GUI admin tool to create, manage, and monitor
EJB 3 timers.

A transaction is a grouping of tasks that must be processed as
an inseparable unit.
Every task that is part of the transaction must succeed in order
for the transaction to succeed.
ACID stands for atomicity, consistency, isolation, and durability.
Atomicity: Transactions are atomic in nature; they either
commit or roll back together.
Consistency: If the system is in a state consistent with the
business rules before a transaction begins, it must remain in a
consistent state after the transaction is rolled back or
committed.
Isolation: The isolation property makes sure transactions do
not step on one another’s toes. Handled by transaction
manager by placing some kind of lock on the data accessed by
a transaction.
Durability: Durability means that a transaction, once
committed, is guaranteed to become permanent, implemented
using transaction logs.

Read uncommitted—At this isolation level, the
transaction can read the uncommitted data of other
transactions, also known as a “dirty” read. One should not
use this level in a multithreaded environment.
Read committed—The transaction will never read
uncommitted changes from another transaction. This is
the default level for most databases.
Repeatable read—The transaction is guaranteed to get
the same data on multiple reads of the same rows until
the transaction ends.
Serializable—This is the highest isolation level and
guarantees that none of the tables you touch will change
during the transaction, including adding new rows. This
isolation level is very likely to cause performance
bottlenecks.

In enterprise transaction management, the
component that takes care of transactions for a
particular resource is called a resource manager.
A resource can be database or a message server.
A transaction that uses a single resource is called a
local transaction.
The transaction manager is a component that
coordinates a single transaction over multiple
distributed resources.
The transaction manager coordinates application
requests among multiple resource managers, and
each transaction phase may translate to numerous
low-level resource commands issued by the resource
managers.

The two-phase commit protocol performs an
additional preparatory step before the final commit.
During this step, each resource manager involved is
asked if the current transaction can be successfully
committed.
If any of the resource managers indicate that the
transaction cannot be committed if attempted, the
entire transaction is abandoned (rolled back).
Otherwise, the transaction is allowed to proceed and
all resource managers are asked to commit.
Only distributed transactions use the two-phase
commit protocol.

It enables to declaratively, done through
annotations or the deployment descriptor.
In a CMT, the container starts, commits, and
rolls back a transaction on our behalf.
Transaction boundaries in declarative
transactions are always marked by the start and
end of EJB business methods.
By default, the container assumes to use CMT
on all business methods.

@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
public class OrderManagerBean {
@Resource
private SessionContext context;
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void placeSnagItOrder(Item item, Customer customer){
try {
if (!bidsExisting(item)){
validateCredit(customer);
chargeCustomer(customer, item);
removeItemFromBidding(item);
}
} catch (CreditValidationException cve) {
context.setRollbackOnly();
} catch (CreditProcessingException cpe){
context.setRollbackOnly();
} catch (DatabaseException de) { context.setRollbackOnly(); }
}
}

The @TransactionManagement annotation specifies
whether CMT or BMT is to be used for a particular
bean.
TransactionManagementType.CONTAINER means the
container should manage transactions on the bean’s
behalf.
TransactionManagementType.BEAN enables to to
manage transactions programmatically.
If we do not specify the @TransactionManagement
annotation or the transactiontype element in the
deployment descriptor, the container assumes that
we intend to use a CMT.

It enables to tell the container how it should
manage transactions.
The transaction wraps around the bean’s
method could be started by the container
specifically when calling the method, or it
could be inherited from a client calling the
method.
The annotation can be applied either to
individual CMT bean methods or to the entire
bean.
If the @TransactionAttribute annotation is

Transaction
Attribute
Caller Transaction
Exists?
Effect
REQUIRED No Container creates a new transaction.
Yes Method joins the caller’s transaction.
REQUIRES_NEW No Container creates a new transaction.
Yes Container creates a new transaction and
the caller’s transaction is suspended.
SUPPORTS No No transaction is used.
MANDATORY No javax.ejb.EJBTransactionRequired-
Exception is thrown.
NOT_SUPPORTED No No transaction is used.
Yes The caller’s transaction is suspended and the
method is
called without a transaction.
NEVER No No transaction is used.
Yes javax.ejb.EJBException is thrown.

REQUIRED: It is a default value and specifies that the EJB
method must always be invoked within a transaction.
If the method is invoked from a nontransactional client the
container will start a transaction before the method is called
and finish it when the method returns.
If the caller invokes the method from a transactional context,
the method will join the existing transaction
REQUIRES_NEW: This value indicates that the container must
always create a new transaction to invoke the EJB method.
If the client already has a transaction, it is temporarily
suspended (paused) until our method returns and then
resumed.
The success or failure of the new transaction has no effect on
the existing client transaction.

SUPPORTS: It essentially means the EJB method will inherit
whatever the transactional environment of the caller is.
If the caller does not have a transaction, the EJB method will
be called without a transaction.
If the caller is transactional, the EJB method will join the
existing transaction and won’t cause the exiting transaction to
be suspended.
MANDATORY: It means requires existing—that is, the caller
must have a transaction before calling an EJB method and the
container should never create a transaction on behalf of the
client.
If the EJB method using the MANDATORY attribute is invoked
from a nontransactional client, the container throws an
EJBTransactionRequiredException.

NOT_SUPPORTED: When assigned this transaction
attribute, the EJB method cannot be invoked in a
transactional context.
If a caller with an associated transaction invokes the
method, the container will suspend the transaction,
invoke the method, and then resume the transaction
when the method returns. Used for MDBs.
NEVER: This attribute means that the EJB method can
never be invoked from a transactional client.
If such an attempt is made, a javax.ejb.EJBException is
thrown.

The transaction is never rolled back
immediately, but a flag is set for the container
to do the actual rollback when it is time to end
the transaction.
The getRollbackOnly method returns a boolean
telling whether the underlying CMT transaction
has already been marked for rollback.
The setRollbackOnly and getRollbackOnly
methods can only be invoked in an EJB using
CMT with these transaction attributes:
REQUIRED, REQUIRES_NEW, or MANDATORY.

Transactional outcome is controlled through the
@javax.ejb.ApplicationException annotation to avoid the all-
too-common exception handling code.
The @ApplicationException annotation identifies a Java
checked or unchecked exception as an application exception.
By default, all checked exceptions except for
java.rmi.RemoteException are assumed to be application
exceptions and handled by the method invoker.
All exceptions that inherit from either
java.rmi.RemoteExceptions or java.lang.RuntimeException are
assumed to be system exceptions are not passed to the client
as it is but are wrapped in a javax.ejb.EJBException instead.
Setting the rollback element to true (default is false) tells the
container that it should roll back the transaction before the
exception is passed on to the client.

public void placeSnagItOrder(Item item, Customer customer)
throws CreditValidationException,
CreditProcessingException, DatabaseException {
if (!bidsExisting(item)){ …… }
}
...
@ApplicationException(rollback=true)
public class CreditValidationException extends Exception { …. }
...
@ApplicationException(rollback=true)
public class CreditProcessingException extends Exception { … }
...
@ApplicationException(rollback=false)
public class DatabaseException extends RuntimeException { … }

CMT notifies about the transaction’s lifecycle events.
CMT bean implements the
javax.ejb.SessionSynchronization interface which
defines three methods:
void afterBegin()—Called right after the container
creates a new transaction and before the business
method is invoked.
void beforeCompletion()—Invoked after a business
method returns but right before the container ends a
transaction.
void afterCompletion(boolean committed)—Called
after the transaction finishes. The boolean committed
flag indicates whether a method was committed or
rolled back.

@Stateless)
@TransactionManagement(TransactionManagementType.BEAN)
public class OrderManagerBean {
@Resource
private UserTransaction userTransaction;
public void placeSnagItOrder(Item item, Customer customer){
try {
userTransaction.begin();
if (!bidsExisting(item)){
validateCredit(customer);
chargeCustomer(customer, item);
removeItemFromBidding(item);
}
userTransaction.commit();
} catch (CreditValidationException cve) { userTransaction.rollback();
} catch (CreditProcessingException cpe){ userTransaction.rollback();
} catch (DatabaseException de) { userTransaction.rollback();
} catch (Exception e) { e.printStackTrace();
}
}
}

The UserTransaction interface encapsulates the basic
functionality provided by a Java EE transaction manager.
The UserTransaction can be accessed in by injecting it
through the @Resource annotation.
The application server can bind the UserTransaction to the
JNDI name java:comp/ UserTransaction, and used
context.lookup("java:comp/UserTransaction") method to
acccess the UserTransaction.
UserTransaction can be access from the
getUserTransaction method of the EJBContext (either
SessionContext or MessageDrivenContext) only when
using BMT.
The methods getRollbackOnly and setRollbackOnly of
EJBContext cannot be used in BMT causing container to
throw an IllegalStateException.

public interface UserTransaction {
void begin() throws NotSupportedException,
SystemException;
void commit() throws RollbackException,
HeuristicMixedException, HeuristicRollbackException,
SecurityException, IllegalStateException, SystemException;
void rollback() throws IllegalStateException,
SecurityException, SystemException;
void setRollbackOnly() throws IllegalStateException,
SystemException;
int getStatus() throws SystemException;
void setTransactionTimeout(int seconds) throws
SystemException;
}

The begin method creates a new low-level transaction
behind the scenes and associates it with the current
thread.
The commit and rollback methods, on the other hand,
remove the transaction attached to the current
thread by using the begin method.
The getStatus method returns an integer-based status
of the current transactions, indicating a more fine-
tuned set of states a transaction could possibly be in.
The javax.transaction.Status interface defines the
transaction states.
The setTransactionTimeout method specifies the
time, in seconds, in which a transaction must finish.

Status Description
STATUS_ACTIVE transaction is in an active state
STATUS_MARKED_ROLLBACK transaction is marked for rollback
STATUS_PREPARED transaction is in the prepared state because all
resources have agreed to commit
STATUS_COMMITTED associated transaction has been committed
STATUS_ROLLEDBACK associated transaction has been rolled back
STATUS_UNKNOWN status for associated transaction is not known
STATUS_NO_TRANSACTION no associated transaction in the current thread
STATUS_PREPARING associated transaction is preparing to be committed and
awaiting response from subordinate resources
STATUS_COMMITTING transaction is in the process of committing
STATUS_ROLLING_BACK transaction is in the process of rolling back

BMT transactions need not begin and end in the
confines of a single method call, hence useful to
maintain a transaction across method calls.
(Though this is error prone and not preferred
approach.)
BMT enables to fine-tune the transaction
boundaries so that the data held by the code is
isolated for the shortest time possible.
Drawback of BMT is the fact that it can never join
an existing transaction.
Existing transactions are always suspended when
calling a BMT method, significantly limiting flexible
component reuse.

EJB3 Advance Features

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to EJB3 Advance Features (20)

More from Emprovise (20)

Recently uploaded (20)

EJB3 Advance Features