Anticipating a Listener

In some situations, a sending CM transport can anticipate the request for certified delivery from a (listener) persistent correspondent that has not yet registered.

Consider an example in which a database program (DB) records all messages with the subject STORE.THIS. The program DB creates a CM transport that instantiates a persistent correspondent named DB_PER. All programs that send messages with the subject STORE.THIS depend on this storage mechanism.

One such sending program is JAN. Whenever JAN starts, it can anticipate that DB_PER will request certified delivery of the subject STORE.THIS. Suppose that JAN starts, but DB is not running, or a network disconnect has isolated JAN from DB. Anticipating that it will eventually receive a registration request for STORE.THIS from DB_PER, JAN makes an add listener call. The effect is that the sending CM transport in JAN behaves as if it has a certified delivery agreement with DB_PER for the subject STORE.THIS; it stores outbound messages (on that subject) in its ledger. When DB restarts, or the network reconnects, the sender CM transport in JAN automatically retransmits all the stored messages to DB_PER.

It is not sufficient for a sender to anticipate listeners; the anticipated listening programs must also require old messages when they create their CM transports.

The sending transport must be available to process the registration request and redeliver stored messages (if necessary).

Table 29 Add Listener Calls
C	tibrvcmTransport_AddListener()
C++	TibrvCmTransport::addListener()
Java	TibrvCmTransport.addListener()
.NET	CMTransport.AddListener