When an event is consumed from a queue transactionally, there is a chance that the transaction will be rolled back. This could be triggered by the user or by a disconnection. When this happens, the event needs to be put onto the queue for redelivery.

When a message is rolled back it is re-added to the front of the queue and is assigned a new event ID. So if an event is rolled back, that event will be added straight back at the front of the queue ready for redelivery. The API method event.getHeader().getOriginalTransactionEID() returns the event ID that the event had when it was first published to the queue; this value is only set on republish.

Note that for performance reasons Universal Messaging delivers a window of messages to the client. By default there will be 10 messages waiting in the client to be delivered to the user, so if the user rolls back event 0, they will receive the window of events already on the client before they consume event 0 again.

It is possible to set the client window to be only 1 event, and doing so will guarantee event ordering. The window size is set on the nQueueReaderContext and is only relevant for asynchronous consumers. Using a small window size affects the performance negatively, since this increases the number of windows Universal Messaging server has to deliver. Therefore, if your application does not require rolled-back events to be ordered, we suggest leaving the default windows size unaltered.