By default, a broker discards a publication after it has sent that publication to all interested subscribers. However, a publisher can specify that it wants the broker to keep a copy of a publication, which is then called a retained publication.
A copy of a retained publication is sent by the broker to all subscribers who register an interest in the topic of the publication. This means that a new subscriber does not have to wait for information to be published again before they receive it.
For example, a subscriber that registers a subscription to a stock price receives the most recently published price straightaway, without having to wait for the stock price to change and be republished.
If RetainPub is specified as a publication option in the Publish message, the publication is retained by the broker and replaces any previously retained publication for that topic.
Because the broker retains only one publication for each topic and subscription point, the old publication is deleted when a new publication arrives.
When deciding whether to use retained publications, you should consider the following factors.
Typically, event information is not retained, but state information is retained. However, if all the subscriptions to a topic are in place before any publications are made on that topic, and if no new subscriptions are expected, there is no need to retain publications, even for state information, because the publications are delivered to all subscribers as soon as they are published.
Publications of state information might also not need to be retained if they are published very frequently (for example, every second). With this frequency of publishing, any new subscriber (or a subscriber recovering from a failure) receives the current state almost immediately after it subscribes.
If you use retained publications, subscribers can register using the PubOnReqOnly option of the Register Subscriber message. This means that the broker sends publications to a subscriber only when that subscriber requests an update. The broker then sends to the subscriber the current retained publication that matches the subscription.
This is not recommended. If you have a retained publication, and then publish a non-retained publication on the same topic, the existing retained publication is still retained. It is not updated by the non-retained publication. If a subscriber registers using the PubOnReqOnly option of the Register Subscriber message, it cannot access any non-retained publications. The broker sends only the current retained publication in response to a request for an update.
You are recommended to not have more than one application publishing retained publications on the same topic. If you do, and the timing is close to simultaneous, it is indeterminate which publication is retained. If the publishers use different brokers, different retained publications for the same topic might be held at each broker.
If the publisher does not use retained publications, the subscriber application might need to store its current state locally. If the publisher uses retained publications, the subscriber can request an update to refresh its state information after a restart.
The broker continues to send publications to a registered subscriber even if that subscriber is not running. This can lead to a buildup of messages on the subscriber queue. This buildup can be avoided if the subscriber registers with the PubOnReqOnly option of the Register Subscriber message. The subscriber must then refresh its state periodically either by requesting an update or by using a temporary dynamic queue.
The broker needs to store retained publications in a database. This reduces throughput. If the publications are very large, a considerable amount of disk space is needed to store the retained publication of each topic. In a multi-broker environment, retained publications are stored by all other connected brokers that have a matching subscription.
Use the Expiry field of the message descriptor (MQMD) to set an expiry interval for a retained publication.
The sample verification applications that are shipped with WebSphere Business Integration Message Broker include the Soccer Results service. This sample uses retained publications to record the latest score in each soccer match that it is monitoring. The sample code illustrates the programming that is required to support this option.
MQ | MQe | SCADA | JMS/IP | |
---|---|---|---|---|
Retained | YES | YES | YES | NO |
Expiry Date | YES | YES | NO | NO |
The columns in the table indicate what type of application the rows refer to. The first row indicates whether a publication can be a retained publication, and the second row indicates whether an expiry date can be applied to the publication.
Related concepts
Publications
Subscriptions
Related tasks
Publishing
Subscribing
De-registering a subscription
Related reference
Publish message
Register Subscriber message
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
aq13030_ |