A message may be redelivered if it was previously received but not acknowledged. For example, the message was received but
the application receiving the message did not complete processing the message content before it crashed. In these cases, QAnywhere
marks the message as redelivered to alert the receiver that the message might be partly processed.
For example, assume that the receipt of a message occurs in three steps:
An application using a non-transactional QAnywhere manager receives the message.
The application writes the message content and message ID to a database table called T1, and commits the change.
The application acknowledges the message.
If the application fails between steps 1 and 2 or between steps 2 and 3, the message is redelivered when the application restarts.
If the failure occurs between steps 1 and 2, you should process the redelivered message by running steps 2 and 3. If the failure
occurs between steps 2 and 3, then the message is already processed and you only need to acknowledge it.
To determine what happened when the application fails, you can have the application call ml_qa_getredelivered to check if
the message has been previously redelivered. Only messages that are redelivered need to be looked up in table T1. This is
more efficient than having the application access the received message's message ID to check whether the message is in the
table T1, because application failures are rare.
You can read this header after a message is received and until a rollback or commit occurs; after that you cannot read it.
In the following example, a message is received; if the message was previously delivered but not received, the message ID
is output to the database server messages window:
declare @msgid varchar(128);
declare @redelivered bit;
set @msgid = ml_qa_getmessage( 'myaddress' );
set @redelivered = ml_qa_getredelivered( @msgid );
if @redelivered = 1 then
message 'message with message ID ' || @msgid || ' has been redelivered';