Application Deployment

Sample Application

A sample job monitor application is delivered in the examples/development/applications/ExampleJobMonitorMDB directory. This sample writes the job status information to the server log for each job status message received. Both the source Java code and a deployable EAR file are supplied, along with instructions for deployment (see the PDF file in the examples/development/applications/ExampleJobMonitorMDB directory).

Enabling Durable Messaging

By default, the messaging configuration of an MDB is non-durable. This means that if the MDB application is not running at the time a job event is generated, the event is discarded. The application is not aware that it missed events when it is restarted. This configuration is the most efficient and suitable for many applications. However, if the MDB application must be (reliably) notified of all job events (even events that occurred when the MDB application was not running), the message configuration must be changed.

This can be changed in the MDB application’s XML deployment descriptor, or it can be specified in annotations in the MDB source code. The example application uses annotations similar to the following to define the deployment options, including message durability:

@MessageDriven (mappedName = "fiper/jms/jobmonitor", 
activationConfig = {
@ActivationConfigProperty
(propertyName="destinationType",propertyValue="javax.jms.
Topic"),
@ActivationConfigProperty (
propertyName="subscriptionDurability", 
propertyValue="NonDurable"
)
})

Changing the "NonDurable" property value to "Durable" causes the message system to hold (in persistent storage) messages that cannot be delivered. When the MDB application restarts, all held messages are delivered. This can improve the reliability of the system, at the expense of some overhead and the potential to fill the queuing system if the MDB application is unavailable for a significant length of time.