Universal Messaging 10.3 | Concepts | Durable Subscriptions | Types of Durable Subscription
 
Types of Durable Subscription
Universal Messaging offers several types of durable subscription. Each of these types allows the durable subscription to be managed in a different way.
The available types are:
*Exclusive (also called Named)
*Priority
*Shared
*Shared-Queued
*Serial
These types are described in the following sections.
Durable Type "Exclusive"
Figure 3. Exclusive durable: Client session C1 is subscribed and connected to the durable. No other client sessions are allowed to subscribe to the same durable while the current client session is active and subscribed.
With this durable type, only one client session can be subscribed and connected to the durable subscription at a time. Other clients will not be allowed to subscribe while the current client session is subscribed.
Each read operation issued by a client returns a single event from the durable to the client. The client processes the event according to the client's application logic, then returns an acknowledgement to the durable that the event has been processed. Each subsequent read operation by the client returns the next event from the durable in chronological order.
If the client connection is terminated, a subsequent client connection on the durable will restart at the next unacknowledged event on the durable.
Durable Type "Priority"
Note:
This durable type is deprecated in Universal Messaging version 10.3 and will be removed in a later version. For future applications we suggest you use the durable type Serial instead of Priority.
Figure 4. Priority durable: Clients sessions C1 and C2 are subscribed. C1 currently has priority and will process all of the events. If C1 goes offline, C2 will take over.
With this durable type, multiple client sessions can be subscribed and connected, but only one client session has priority. The priority client is the only client that can receive events from the durable.
The read/process/acknowledge cycle for this durable type is the same as for the Exclusive durable type.
If the priority client session goes offline, the next subscribed client will become the priority client, and processing will restart at the next unacknowledged event on the durable.
Durable Type "Shared"
Figure 5. Shared durable: Multiple active client sessions are allowed and are served in a round-robin manner. Each client receives a window of events. This is also the model used for the Serial durable type, but there are differences as to how the clients process their assigned event windows.
Note:
The diagram applies for both Shared and Serial durable types. The difference between these types lies in the way that windows of events are processed. See the description below and the description for Shared durables for a comparison.
With this durable type, multiple clients can be subscribed, and they will receive events from the durable in round-robin fashion. You can configure the durable so that each client receives a window consisting of multiple events instead of a single event. As soon as one client has received its allotted event or window of events, the next client receives its events, and so on. Thus, all subscribed clients on the durable can be processing events concurrently.
The chronological order in which events are processed is not guaranteed. For example: a client C1 receives a window of events, then client C2 receives a window of events, but C2 completes its processing and acknowledges its events before C1 completes its processing.
Durable Type "Shared-Queued"
Note:
This durable type is deprecated in Universal Messaging version 10.3 and will be removed in a later version. For future applications we suggest you use the durable type Shared instead of Shared-Queued.
Figure 6. Shared-Queued durable: The principle is the same as for Shared, but the internal implementation involves a queue mechanism. Multiple active client sessions are allowed and are served in a round-robin manner. Each client receives a window of events, but clients do not process their windows concurrently.
This durable type provides the same functionality as the Shared durable type, but is based on an implementation that uses an internal queue to maintain copies of events that are assigned to the durable. Under certain circumstances, for example if you are running Universal Messaging in a clustered environment where synchronization of queues across all nodes in the cluster is required, the handling of such queues may affect performance.
Note: 
If you use a JMS trigger on a Shared-Queued durable with multiple concurrent clients, and the trigger has a sleep time that is longer than the timeout of the concurrent clients, this will cause the event processing to loop between the Pending and Rollback states.
In such cases, you could consider using a Shared durable rather than a Shared-Queued durable, or set the trigger's sleep time to a value lower than the timeout of the concurrent clients.
Shared-Queued is the original implementation of the functionality available in Shared. You may wish to consider using Shared instead of Shared-Queued for any new applications you develop, as Shared uses an indexing mechanism directly on the events in the channel rather than a queue-based mechanism.
Durable Type "Serial"
This durable type offers the same functionally as Shared, but ensures that events are processed in chronological order.
See the diagram for Durable Type "Shared" for reference.
Multiple client sessions can be subscribed, and they will receive events from the durable in round-robin fashion. Also a window size can be defined to allow multiple events to be assigned to each client. The difference to the Shared type is that a client will only receive its event or window of events when the previous client has acknowledged its events. Therefore while any client is processing its events, the other subscribed clients are inactive.
There is a special case when there is only one client session subscribed: if this client acknowledges some, but not all, of the events in the current window, Universal Messaging immediately sends the client the same number of new events from the next window instead of waiting until the client has acknowledged all of the events in the current window. This means that the client again has a number of unacknowledged events equal to the size of a window. Example: assume the window size is 10 and there is only one client session. If the client acknowledges 4 events from the first window of 10 events, Universal Messaging immediately sends 4 new events from the second window, so that the client is again working with a full set of 10 unacknowledged events. This pattern is repeated every time the client acknowledges events.