TIBCO Rendezvous supports preregistration for RVCM sessions. In some situations, a sending RVCM session 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 an RVCM session 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 sending RVCM session 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 RVCM session in JAN automatically retransmits all the stored messages to DB_PER.
The SDK supports endpoint types (TIBCO Rendezvous publishers and subscribers, TIBCO Rendezvous CM publishers and subscribers) that result in preregistration of the specified listener.