> How EMS Manages Persistent Messages
> As described in Message Delivery Modes. JMS defines two message delivery modes, PERSISTENT and NON_PERSISTENT, and EMS defines a RELIABLE_DELIVERY mode.
> NON_PERSISTENT and RELIABLE_DELIVERY messages are never written to persistent storage. PERSISTENT messages are written to persistent storage when they are received by the EMS server.
> Persistent Messages Sent to Queues
> Persistent messages sent to a queue are always written to disk. Should the server fail before sending persistent messages to subscribers, the server can be restarted and the persistent messages will be sent to the subscribers when they reconnect to the server.
> Figure 8 Persistent Messages Sent to a Queue
> Persistent Messages Published to Topics
> Persistent messages published to a topic are written to disk only if that topic has at least one durable subscriber or one subscriber with a fault-tolerant connection to the EMS server. In the absence of a durable subscriber or subscriber with a fault-tolerant connection, there are no subscribers that need messages resent in the event of a server failure. In this case, the server does not needlessly save persistent messages. This improves performance by eliminating the unnecessary disk I/O to persist the messages.
> Figure 9 Persistent Messages Published to a Topic
> This behavior is consistent with the JMS specification because durable subscribers to a topic cause published messages to be saved. Additionally, subscribers to a topic that are connected to a fault-tolerant server need to receive messages from the secondary server after a failover. However, non-durable subscribers that re-connect after a server failure are considered newly created subscribers and are not entitled to receive any messages created prior to the time they are created (that is, messages published before the subscriber re-connects are not resent).
> Persistent Messages and Synchronous File Storage
> When using file storage, persistent messages received by the EMS server are by default written asynchronously to disk. This means that, when a producer sends a persistent message, the server does not wait for the write-to-disk operation to complete before returning control to the producer. Should the server fail before completing the write-to-disk operation, the producer has no way of detecting the failure to persist the message and taking corrective action.
> You can set the mode parameter to sync for a given file storage in the stores.conf file to specify that persistent messages for the topic or queue be synchronously written to disk. When mode = sync, the persistent producer remains blocked until the server has completed the write-to-disk operation.
> Each EMS server writes persistent messages to a store file. To prevent two servers from using the same store file, each server restricts access to its store file for the duration of the server process. For details on how EMS manages shared store files, see How EMS Manages Access to Shared Store Files.

Copyright © TIBCO Software Inc. All Rights Reserved.