This feature is based on requirements that come from the pricing infrastructure world. To elaborate more, in the pricing world the last-value cache is based on a record with multiple fields. A pricing update message may only update at most all fields in this record, identified by keys for fields, which are analogous to updating a row in a database table. Applications registered to the trading broker receive the messages as sent, but when a new application comes along, the first thing it gets from the broker is the complete record (as cached at the time of subscription) followed by the messages updated to the record. This enables trading applications to easily build upon the latest or current trend of trading and thereon to join the stream.
In FioranoMQ context, this is analogous to - each JMS Topic can be used to store the last-value cache or a snapshot of data that can be viewed as current data and each new client subscriber application will obtain the current snapshot first and then get updates to whatever was in the snapshot on an ongoing basis. It should be noted that each update message, before being sent to the subscribers on a particular topic on which Last Value Caching is enabled is also stored in the cache for that topic.
It should also be noted that the snapshot is simply a set of JMS messages, exactly as they were sent by the JMS MessageProducer.