Persistent Messages
Message persistence means that if a queue manager or Embedded JMS server fails, all the messages it holds will be recoverable as they are written to disk.
JMS Provider: WebSphere JMS and WebSphere MQ JMS Component: Queue destination and Topic destination Applies to specific messaging topologies: Yes Requires specific usage of JMS in application: Yes Location of setting: Varies - see text. The configuration of whether a message should be persisted is configurable at three levels:
- Application level - In the application code
When using either the QueueSender or TopicPublisher JMS classes it is possible to specify whether messages should be persistent. This is done using the setDeliveryMode() method which accepts values of either:
- DeliveryMode.NON_PERSISTENT
- DeliveryMode.PERSISTENT
When creating a QueueSender or TopicPublisher, if setDeliveryMode is not used then the default is DeliveryMode.PERSISTENT.
- Queue destination and topic destination settings
Within these objects it is possible to define the persistence. Possible values for persistence are: APPLICATION DEFINED PERSISTENT NON PERSISTENT QUEUE DEFINED (only on the WebSphere MQ JMS provider objects)
- Queue definition in queue manager
For WebSphere MQ it is possible to set the Default Persistence.
Even though you can configure the persistence at each level there are some rules that govern which setting will take precedence:
Setting the value on the WebSphere MQ queue is only the default persistence setting. It is overridden by the setting on the JMS queue and topic destinations.
Any value set in the application code will be overridden by the settings on the queue or topic destination unless they are configured as APPLICATION DEFINED, in which case the value in the application will be used.
Defining PERSISTENT and NON PERSISTENT on the queue and topic definitions is the only way to accurately know from looking at the WAS configuration whether persistence will occur.
If you are using WebSphere MQ (as opposed to Embedded JMS) then you can configure the queue or topic destination to take the default value specified on the queue. This is done using QUEUE DEFINED.
As messages are being stored on disk this reduces the performance of message processing. Persistence should only be used when the topology in use demands it. For example, if you decide to use one queue manager and have it made highly available using some HA software like HACMP, then you will need to have persistent messaging turned on to make this work.
Alternatively, if you have an architecture whereby messages are sent and received in a synchronous fashion, then it might be the case that the client code only waits for a certain amount of time before re-sending the message. In this instance the topology would contain more than one active queue manager and persistent messages would not be required as failures would be masked by retries.
It is not straight forward to decide whether persistence is needed and for this reason it is much better that it not be part of the considerations for a developer. It is recommended that persistence is not specified by the application and is left to the definition of the queue or topic destination so that it is obvious to the administrator whether messages will be persisted.
When a queue or topic destination is defined the default is APPLICATION DEFINED. As the default for creating a new QueueSender or TopicPublisher object in the code is to have messages persisted, the overall defaults for setting up a queue destination are that the message will be persisted. If you do not need messages to be persisted then you need to change the APPLICATION DEFINED to NON PERSISTENT on the queue or topic destination.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.