background image

Deleting the Connection Factory

<< Repackaging the SynchConsumer Example | Using Basic Reliability Mechanisms >>
<< Repackaging the SynchConsumer Example | Using Basic Reliability Mechanisms >>

Deleting the Connection Factory

For examples showing how to deploy Java EE applications on two different systems, see
"An
Application Example That Consumes Messages from a Remote Server" on page 979
and
"An
Application Example That Deploys a Message-Driven Bean on Two Servers" on page 985
.
Deleting the Connection Factory and Stopping the Server
You will need the connection factory jms/JupiterConnectionFactory in
Chapter 32, "Java EE
Examples Using the JMS API."
However, if you wish to delete it, go to the producer directory
and type the following command:
ant delete-remote-factory
Remember to delete the connection factory on both systems.
You can also use Ant targets in the producer/build.xml file to delete the destinations and
connection factories you created in
"Creating JMS Administered Objects for the Synchronous
Receive Example" on page 915
. However, it is recommended that you keep them, because they
will be used in most of the examples in
Chapter 32, "Java EE Examples Using the JMS API."
After you have created them, they will be available whenever you restart the Application Server.
To delete the class and JAR files for each program using NetBeans IDE, right-click each project
and choose Clean Project.
To delete the class and JAR files for each program using Ant, type the following:
ant clean
You can also stop the Application Server, but you will need it to run the sample programs in the
next section.
Creating Robust JMS Applications
This section explains how to use features of the JMS API to achieve the level of reliability and
performance your application requires. Many people choose to implement JMS applications
because they cannot tolerate dropped or duplicate messages and require that every message be
received once and only once. The JMS API provides this functionality.
The most reliable way to produce a message is to send a PERSISTENT message within a
transaction. JMS messages are PERSISTENT by default. A transaction is a unit of work into which
you can group a series of operations, such as message sends and receives, so that the operations
either all succeed or all fail. For details, see
"Specifying Message Persistence" on page 940
and
"Using JMS API Local Transactions" on page 947
.
The most reliable way to consume a message is to do so within a transaction, either from a
queue or from a durable subscription to a topic. For details, see
"Creating Temporary
Destinations" on page 941
,
"Creating Durable Subscriptions" on page 942
, and
"Using JMS API
Local Transactions" on page 947
.
Creating Robust JMS Applications
Chapter 31 · The Java Message Service API
935