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
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.