Purposes of Persistence
The persistence infrastructure of stores and durables can serve four purposes: delivery assurance, apportioning message streams, last-value availability, and key/value maps. These purposes correspond to four types of durables: standard durables, shared durables, last-value durables, and map durables.
Delivery Assurance
An ordinary subscriber receives messages from a publisher only when a transport connects the subscriber with that publisher. That is, an ordinary subscriber cannot receive a message through a direct path transport unless both of these conditions hold at the time that the publisher sends the message:
With persistence, subscribers can receive every message with high assurance, despite temporary lapses in these conditions. For example, a persistence store can retain data for subscriber recovery after application exit and restart, temporary network failure, or application host computer failure.
Stores can retain data indefinitely, until subscribers acknowledge delivery. (In contrast, even reliable transports retain data only for a finite interval.)
For delivery assurance, use standard durables. Standard durables serve one subscriber at a time, and assure that it can receive the whole message stream.
Apportioning Message Streams
In some situations it is convenient to use a shared durable to apportion a message stream among a set of cooperating subscribers so that only one subscriber receives and processes each message, but acting together the subscribers process every message in the stream.
Last-Value Availability
When new subscribers need to receive the current state immediately, but do not need to receive a complete historical message stream, a persistence store can supply the most recent (i.e., last-value) message.
The store continues to forward subsequent messages to subscribers, discarding the previous message as each new message arrives.
For last-value availability, use last-value durables. Last-value durables can serve many subscribers.
A last-value durable divides its input message stream into distinct output streams based on the value of a distinguished key field. In this way, one last-value durable holds more than one last value: one for each key.
Key/Value Map
A key/value map is like a last-value durable without a message stream. It behaves like a simple database table with two columns.
Instead of an inbound message stream to supply values, programs use the map API calls to store and access values. See "Key/Value Maps" in TIBCO FTL Development.