Messaging lifecycle

When a message is put to a queue it progresses through a series of states. This section describes these states and related commands or events under the following headings:

Although, this section gives brief details of algorithms required for assured message delivery, Chapter 7, Message Delivery, provides more information on assured message delivery.

Message states

Most queue types hold messages in a persistent store, for example a hard disk. While in the store, the state of the message varies as it is transferred into and out of the store. As shown in Figure 4:

Figure 4. Stored message state flow
Diagram showing stored message status
flow

In Figure 2, "start" and "deleted" are not actual message states. They are the entry and exit points of the state model. The message states are:

Put unConfirmed
A message is put to the message store of a queue with a confirmID. The message is effectively hidden from all actions except confirmPutMessage or undo.
Unlocked
A message has been put to a queue and is available to all operations.
Locked for Browse
A browse with lock retrieves messages. Messages are hidden from all queries except getMessage, unlock, delete, undo, and unlockMessage. A lockID is returned from the browse operation. You must supply this lockID to all other operations.
Get Unconfirmed
A getMessage call has been made with a confirmID, but the get has not been confirmed. The message is invisible to all queries except confirmGetMessage, confirm, and undo. Each of these actions requires the inclusion of the matching confirmID to confirm the get.
Browse Get Unconfirmed
A message got while it is locked for browse. You can do this only by passing the correct lockID to the getMessage function.

On an asynchronous remote queue, other states exist where a message is being transmitted to another machine. These states are entered as "unlocked", that is only confirmed messages are transmitted.

Message events

Messages pass from one state to another as a result of an event. These events are typically generated by an API call. The possible message events, as shown in Figure 4, are:

putMessage
Places a message on a queue. This does not require a confirmID.
getMessage
Retrieves a message from a queue. This does not require a confirmID.
putMessage with confirmId>0
Places a message on a queue. This requires a confirmID. However, messages do not arrive at the receiving end in the order of sending, but in the order of confirmation.
confirmPutMessage
A confirm for an earlier putMessage with a confirmID>0.
getMessage with confirmId>0
Retrieves message from a queue. This requires a confirmID.
confirmGetMessage
A confirm for an earlier getMessage with a confirmID>0.
browseWithLock
Browses messages and lock those that match. Prevents messages from changing while browse is in operation.
unlockMessage
Unlocks a message locked with a browsewithLock command.
undo
Unlocks a message locked with a browse, undoes a getMessage with a confirmID>0, or undoes a putMessage with a confirmID>0.
deleteMessage
Removes a message from a queue.

Message index fields

Due to memory size constraints, complete messages are not held in memory, but, to enable faster message searching, WebSphere MQ Everyplace holds specific fields from each message in a message index. The fields that are held in the index are:

Java
In Java, the following fields are held in the index:
UniqueID
MQe.Msg_OriginQMgr + MQe.Msg_Time
MessageID
MQe.Msg_ID
CorrelationID
MQe.Msg_CorrelID
Priority
MQe.Msg_Priority
C
In C, the following fields are held in the index:
UniqueID
MQE_MSG_ORIGIN_QMGR + MQE_MSG_TIME
MessageID
MQE_MSG_MSGID
CorrelationID
MQE_MSG_CORRELID
Priority
MQE_MSG_PRIORITY

Providing these fields in a filter makes searching more efficient, since WebSphere MQ Everyplace may not have to load all the available messages into memory.