Java Reference
In-Depth Information
@Resource(lookup = "jms/ConnectionFactory")
private ConnectionFactory connectionFactory;
@Resource(lookup = "jms/Topic")
private Topic topic;
If you declare the resource static in these components, runtime errors will result.
Using Session Beans to Produce and to Synchronously Receive Messages
An application that produces messages or synchronously receives them can use a session
bean to perform these operations. The example in
“
An Application That Uses the JMS
API with a Session Bean
”
on page
416
uses a stateless session bean to publish messages
to a topic.
Because a blocking synchronous receive ties up server resources, it is not a good program-
ming practice to use such a
receive
call in an enterprise bean. Instead, use a timed syn-
chronous receive, or use a message-driven bean to receive messages asynchronously. For
details about blocking and timed synchronous receives, see “
Writing the Clients for the
Synchronous Receive Example
”
on page
378
.
Using the JMS API in an enterprise bean is in many ways similar to using it in an applic-
ation client. The main differences are the areas of resource management and transactions.
Managing JMS Resources in Session Beans
The JMS API resources are a JMS API connection and a JMS API session. In general, it
is important to release JMS resources when they are no longer being used. Here are some
useful practices to follow:
• If you wish to maintain a JMS API resource only for the life span of a business
method, it is a good idea to close the resource in a
finally
block within the
method.
• If you would like to maintain a JMS API resource for the life span of an enterprise
bean instance, it is a good idea to use a
@PostConstruct
callback method
to create the resource and to use a
@PreDestroy
callback method to close the
resource. If you use a stateful session bean and you wish to maintain the JMS
API resource in a cached state, you must close the resource in a
@PrePassiv-
ate
callback method and set its value to
null
, and you must create it again in a
@PostActivate
callback method.
