Tuning Message-Driven Beans

This section provides some tips to improve performance when using JMS with message-driven beans (MDBs).

Use getConnection()

JMS connections are served from a connection pool. This means that calling getConnection() on a Queue connection factory is fast.

Caution –

Previous to version 8.1, it was possible to reuse a connection with
a servlet or EJB component. That is, the servlet could call getConnection() in its init() method and then continually call getSession() for each servlet invocation. If you use JMS within a global
transaction, that no longer works: applications can only call getSession() once for each connection. After than, the connection must be closed (which
doesn’t actually close the connection; it merely returns it to the pool). This
is a general feature of portable J2EE 1.4 applications; the Sun Java System Application
Server enforces that restriction where previous (J2EE 1.3-based) application servers
did not.

Tune the Message-Driven Bean’s Pool Size

The
container for message-driven beans (MDB) is different than the containers for entity
and session beans. In the MDB container, sessions and threads are attached to the
beans in the MDB pool. This design makes it possible to pool the threads for executing
message-driven requests in the container.

Tune the Message-Driven bean’s pool size to optimize the concurrent processing
of messages. Set the size of the MDB pool to, based on all the parameters of the server
(taking other applications into account). For example, a value greater than 500 is
generally too large.

You can configure MDB pool settings in the Admin Console at Configurations >
config-name > EJB Container (MDB Settings). You can also set
it with asadmin as follows:

asadmin set server.mdb-container.max-pool-size = value

Cache Bean-Specific Resources

Use the setMesssageDrivenContext() or ejbCreate() method to cache bean specific resources, and release those resources
from the ejbRemove() method.

Limit Use of JMS Connections

When designing an application that uses JMS connections make sure you use a methodology
that sparingly uses connections, by either pooling them or using the same connection
for multiple sessions.

The JMS connection uses two threads and the sessions use one thread each. Since
these threads are not taken from a pool and the resultant objects aren’t pooled,
you could run out of memory during periods of heavy usage.

One workaround is to move createTopicConnection into the
init of the servlet.

Make sure to specifically close the session, or it will stay open, which ties
up resources.