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, consider the following questions.
- Do your publications contain state information or event information?
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 that contain 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.
- Do you want to receive publications only when you request them?
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.
- Can retained publications be mixed with non-retained publications
on the same topic?
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.
- Can you have more than one application publishing retained publications
on the same topic?
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.
- How does the subscriber application recover from failure?
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.
- What are the performance implications of retaining publications?
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 Event 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.
Not
all applications can publish retained publications, and not all retained publications
can have expiry dates applied to them. The following table shows which applications
can publish retained publications and whether the retained publications can
have an expiry date:
|
MQ |
SCADA |
JMS/IP |
Retained |
YES |
YES |
NO |
Expiry Date |
YES |
NO |
NO |
The columns in the table indicate three types
of application. 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.