Java Reference
In-Depth Information
For example, your application could manage conversations by using application-level se-
quence numbers. An application-level conversation control mechanism with a persistent
conversation state could cache later messages until earlier messages have been processed.
Another way to ensure order is to have each message or message group in a conversation
require a confirmation message that the sender blocks on receipt of. This forces the re-
sponsibility for order back onto the sender and more tightly couples senders to the pro-
gress of message-driven beans.
To create a new instance of a message-driven bean, the container does the following:
• Instantiates the bean
• Performs any required resource injection
• Calls the
@PostConstruct
callback method, if it exists
To remove an instance of a message-driven bean, the container calls the
@PreDestroy
callback method.
Figure 20-9
shows the lifecycle of a message-driven bean.
FIGURE 20-9. Lifecycle of a Message-Driven Bean
Managing Distributed Transactions
JMS client applications use JMS API local transactions (described in “
Using JMS API
Local Transactions
”
on page
366
)
, which allow the grouping of sends and receives within
a specific JMS session. Java EE applications commonly use distributed transactions to en-
sure the integrity of accesses to external resources. For example, distributed transactions
allow multiple applications to perform atomic updates on the same database, and they al-
low a single application to perform atomic updates on multiple databases.
