Normally, events on a channel remain on the channel until they are automatically purged. Reasons for purging can be, for example, because the channel is getting full or because events have exceeded their preconfigured lifespan. In some cases, you may wish to retain events on the channel until they are explicitly acknowledged by a client application.

To cover this requirement, Universal Messaging offers a feature called Durable Subscriptions. A durable subscription provides the ability for the realm server to maintain state for events that are consumed by a specific client on a channel. Then, even if the client is stopped and restarted, the client will continue to consume available events from where it left off. Durable subscriptions can be used regardless of whether you have set up Universal Messaging to use the native fanout engine or the JMS-style fanout engine, and the behavior of the durable subscriptions is the same in both cases.

In this documentation, we also refer to durable subscriptions as simply durables. In previous product releases, we also referred to durable subscriptions as named objects.

There can be multiple durable subscriptions per channel, each identified by a unique name. They operate entirely independently from each other, and are unaware of each other's existence, although they access the same events on the channel.

A durable subscription continues to exist and receive events from the channel, even if there are no clients connected or subscribed. A durable subscription that contains no events also continues to exist. A durable subscription can only be deleted by explicit means, either by the client executing appropriate API code, or by an administrator using the appropriate feature in the Enterprise Manager, or Command Central, or on the command line.

One reason for using durable subscriptions is to facilitate recovery if a client is terminated. For example, if the consumer crashes or you turn off the computer and start up another one, the realm server will remember where that client finished.

Universal Messaging provides the ability to consume messages synchronously or asynchronously from durables.

There are different ways in which events consumed by clients can be acknowledged. By specifying 'auto acknowledge' when constructing either the synchronous or asynchronous client session, each event delivered to the client is automatically acknowledged as consumed. If 'auto acknowledge' is not set, then each event consumed has to be acknowledged explicitly by the client.

Durable subscriptions are persistent. This means that if the Universal Messaging realm server is stopped and restarted, the processing of durable subscriptions by connected clients continues from where it stopped.

All durable subscriptions can be specified as "cluster wide". If the durable subscription is cluster wide and it exists on a cluster wide channel, the durable subscription will also be replicated across the cluster.

There are several types of durable subscription, as described in the following section Types of Durable Subscription.

Durable subscriptions of type Exclusive and Priority allow only one active client. For these durable subscriptions, Universal Messaging maintains an internal record of events until the client has received the events. When the client acknowledges (i.e. informs the realm server) that it has received a certain event from the durable subscription, Universal Messaging deletes this event from the internal record and all other events in the internal record that have a lower event ID (i.e. were created at an earlier time).

There are some cases in which it may be desirable for two or more consumers to access a durable subscription at the same time. Universal Messaging offers such functionality with the durable types Shared, Shared-Queued and Serial. These durable subscriptions allow multiple consumers to access the same durable subscription. Universal Messaging delivers events to the consumers in round-robin fashion. So, for example, if there are 10 events in the durable subscription and two consumers who share the durable subscription, then Universal Messaging will deliver events 1, 3, 5, 7, 9 to the first consumer and events 2, 4, 6, 8, 10 to the second consumer.

A typical use case is load balancing, where multiple servers are available to process a stream of events.

If an event for an asynchronous durable subscription of type Shared, Shared-Queued or Serial has been rolled back, the event is immediately re-delivered. In addition, the event's redelivery count is incremented and the event's redelivery flag is set.

If an event for an asynchronous durable subscription of type Exclusive or Priority has been rolled back, the event is re-delivered after a re-subscription; this prevents duplicate events from being received. Note that in this case, the event's redelivery count and redelivery flag are left unchanged.