Using read ahead with IBM MQ classes for JMS
The read ahead functionality that is provided by IBM® MQ allows non-persistent messages that are received outside of a transaction to be sent to the IBM MQ classes for JMS before an application requests them. The IBM MQ classes for JMS store the messages in an internal buffer, and pass the messages to the application when the application asks for them.
IBM MQ classes for
JMS applications that use MessageConsumers or MessageListeners to receive messages from a destination outside of a transaction can use the read ahead functionality. Using read ahead allows applications that use these objects to benefit from improved performance when they receive messages.
MessageConsumers or MessageListeners can use read ahead depends upon the following properties:-
The JMS Destination Property READAHEADALLOWED (short name - RAALD ). READAHEADALLOWED controls whether JMS applications can use read ahead when getting or browsing non-persistent messages outside of a transaction, if the underlying queue or topic that the JMS Destination represents, allows this option.
-
The IBM MQ queue or topic property DEFREADA (Default read ahead). DEFREADA specifies whether applications that are receiving or browsing non-persistent messages outside of a transaction can use read ahead.
The following table shows the possible values for the READAHEADALLOWED and DEFREADA properties, and what values are required for the read ahead functionality to be enabled:
| IBM MQ destination property | READAHEADALLOWED= YES | READAHEADALLOWED= NO | AS_DEST or AS_Q_DEF or AS_T_DEF |
|---|---|---|---|
| IBM MQ queue property | |||
| DEFREADA = NO | Read ahead functionality enabled | Read ahead functionality not enabled | Read ahead functionality not enabled |
| DEFREADA = YES | Read ahead functionality enabled | Read ahead functionality not enabled | Read ahead functionality enabled |
| DEFREADA = DISABLED | Read ahead functionality not enabled | Read ahead functionality not enabled | Read ahead functionality not enabled |
MessageConsumer or MessageListener is created by an application, the IBM MQ classes for
JMS create an internal buffer for the destination that the MessageConsumer or MessageListener is monitoring. There is one internal buffer for each MessageConsumer or MessageListener. The queue manager starts sending non-persistent messages to the IBM MQ classes for
JMS when the application calls one of the following methods:MessageConsumer.receive()MessageConsumer.receive(long timeout)MessageConsumer.receiveNoWait()Session.setMessageListener(MessageListener listener)
The IBM MQ classes for JMS automatically returns the first message back to the application, by the method call that the application has made. The other non-persistent messages are stored by the IBM MQ classes for JMS in the internal buffer that was created for the destination. When the application requests the next message to process, the IBM MQ classes for JMS will return the next message in the internal buffer.
The IBM MQ classes for JMS requests more non-persistent messages from the queue manager when the internal buffer is empty.
The internal buffer that is used by the IBM MQ classes for
JMS is deleted when an application closes a MessageConsumer, or the JMS Session that a MessageListener is associated with.
For MessageConsumers, any unprocessed messages in the internal buffer is lost.
When using MessageListeners, what happens to the messages in the internal buffer depends upon the JMS destination property READAHEADCLOSEPOLICY (short name - RACP). The default value of the property is DELIVER_ALL, which means that the JMS session that was used to create the MessageListener is not closed until all of the messages in the internal buffer are delivered to the application. If the property is set to DELIVER_CURRENT, then the JMS session will be closed after the current message has been processed by the application and all of the remaining messages in the internal buffer are discarded.