Java Reference
In-Depth Information
A message may be delivered to a message-driven bean within a transaction context, so that all
operations within the
onMessage
method are part of a single transaction. If message processing is
rolled back, the message will be redelivered.
Session beans and entity beans are able to send JMS messages and to receive them synchronously,
but not asynchronously. To avoid tying up server resources, it may be better not to use blocking
synchronous receives in a server-side component. To receive messages asynchronously, a message-
driven bean has to be used.
You can see that the development of a message-driven bean is fairly straightforward. The
onMessage
method is the only method a bean developer has to write. Note that various application servers have
different mechanisms to write text to their council screen. Before deploying the
MessageEchoEJB
to
your favorite application server, you may need to replace
println
function in the following code with
function calls appropriate to the server you use:
System.out.println("A message received: " + s);
During the deployment phase, the bean is associated to a JMS destination, either a message queue or
a topic. The JMS destination is where the message-driven bean receives its message. It is specified in
the deployment descriptor as follows:
<message-driven-destination>
<jms-destination-type>javax.jms.Topic</jms-destination-type>
</message-driven-destination>
<message-driven-descriptor>
<destination-jndi-name>SimpleTopic</destination-jndi-name>
</message-driven-descriptor>
Notice that the
MessageEchoEJB
is associated to the JMS topic, "
SimpleTopic
".
So far you have learned all three types of EJBs. Let us moved to EJB transaction management.
EJB Transactions
Transactions
are a big part of most enterprise applications. A transaction consists of multiple data-
updating steps as an indivisible unit of work. Execution of a transaction may end in two ways:
commit
or
rollback
. When a transaction commits, the data modifications made by its statements are saved. If one
of the multiple steps within a transaction fails, the transaction rolls back, undoing the effects of all steps
in the transaction.
The EJB architecture provides for two kinds of transaction demarcation: container-managed transaction
and bean-managed transaction, as discussed in the following sections.
Container-Managed Transaction
For EJBs with
container-managed transactions
, the EJB container sets the boundaries of the
transactions. Container-managed transactions can be used with any type of EJBs: session bean, entity
beans, or message-driven beans. Container-managed transactions significantly simplify development
because the EJB code does not explicitly mark the transaction boundaries. The code does not include
statements that begin and end the transaction.
Typically, the container begins a transaction immediately before an EJB method starts. It commits the
transaction just before the method exits. Each method can be associated with a single transaction.
Nested or multiple transactions are not allowed within a method in the current EJB standard. Container-
managed transactions do not require all methods to be associated with transactions. When deploying
an EJB, one specifies which of the bean's methods are associated with transactions by setting the
transaction attributes.
