The Universal Messaging Queue and Channel Fanout Engines are used to store and forward events based on the channel type. JMS uses topics and messages which are equivalent to Universal Messaging channels and events respectively.

Universal Messaging offers several channel types, each of which have different requirements when storing data. The available channel types are summarized in the section Channel Attributes in the Universal Messaging Concepts guide.

The Fanout Engine for Universal Messaging Provider for JMS uses different criteria to determine storage of events. No replay of messages means that it is not necessary to store events if there is no interest on the channel or once they have been consumed regardless of the channel type. Durable Subscribers require the engine to store the events until the subscriber becomes active and consumes the events. For more information, see Engine Differences.

The Fanout Engine for Universal Messaging Provider for JMS deals with events published to channels based on 'interest'. If there is no interest present on the channel then any events published can be immediately discarded due to no replay of messages. The channel is said to have no interest if there are no durable or active subscribers.

It is often the case that a subscriber needs to receive all events published to a channel including the events published when the subscriber is inactive. With a durable subscriber, any events published while the subscriber is inactive are stored until the subscriber reconnects and consumes the events missed.

When a JMS subscription is made to a channel, the subscription always begins from the last issued event ID. As no events can be consumed more than once, there is no need to store events once they are consumed. This improves the efficiency of the system because all events can be fanned out to subscribers and then dropped straight away (as long as there are no synchronous consumers or inactive durable subscriptions). This greatly reduces the overhead caused by I/O.

Only in the case of inactive durable subscribers or synchronous consumers are events stored. Once all durable subscribers or synchronous consumers have consumed an event, it is removed from storage as there is no need for it to be kept. Synchronous consumers require the events to be stored because they do not receive events fanned out to all consumers, instead they iterate through the events requesting each event in turn.

In the case that a subscriber loses connection to the server, the JMS engine will register a need to temporarily store events for a configurable period of time or until the client reconnects. The time period is defined by the TTL value of the event (if this is non zero) or the EventTimeout value stored in the realm configuration/ClientTimeoutValues under the config tab in the Enterprise Manager which is 60 seconds by default.

The table below shows the storage differences between the JMS Engine and the Universal Messaging Queue and Channel Engines. The Universal Messaging engines store events based on the channel type whereas the JMS Engine only stores events when there are synchronous consumers or inactive durable subscribers. The channel type does however determine where the data is stored.

On a Mixed channel, persistent storage to disk or to memory can be individually set on a per-event basis. When appropriate, events on Persistent channels will be stored to disk, and events on Reliable and Simple channels will be stored in memory. Transient channels do not store events prior to delivery.

1. For a shared durable consumer, events will always be persisted in an internal queue for that specific subscriber, but not on the channel.

2. For a regular durable consumer, using auto-acknowledgment, events will be passed on to the subscriber and not stored on the channel.

3. For a regular durable consumer, using client acknowledgment, events will be stored on the channel. When the subscriber acknowledgment arrives, the event will be removed from the channel.

For further information on storage methods, see the section Named Objects and Shared Named Objects.