Correlator-integrated messaging for JMS can be used with or without the correlator's state persistence feature. In a persistent correlator, all reliability modes can be used (both reliable and unreliable messaging), but in a non-persistent correlator only BEST_EFFORT (unreliable) messaging is supported, and attempts to add senders or receivers using any other reliability will result in an error.

In a persistent correlator, information about all senders and receivers is always stored in the persistent data store - unreliable ones as well as reliable, statically defined as well as dynamic. This means that persistent Apama applications never need to worry about re-creating previously-added JMS senders and receivers after recovery, as this will happen automatically - even for BEST_EFFORT (unreliable) senders and receivers; if also means that for reliable sender and receivers no messages or duplicate detection information will be lost after a crash or restart.

Note that because sender and receiver information is stored in the database, it is not permitted to start a persistent correlator, shut it down, then make changes such as removing existing static senders and receivers in the configuration file before restarting. If the ability to remove senders and receivers is required, they must be added dynamically using EPL rather than from the configuration file. However, you can add new senders and receivers to the configuration files between restarts, provided the identifiers do not clash with any previously defined static or dynamic sender or receiver.

It is not possible to change the configuration of dynamic senders or receivers once created under any circumstances. For static senders and receivers this is also mostly prohibited, with the exception that the destination of a static receiver defined explicitly in the configuration file can be changed between restarts of the Correlator (provided the receiverId and dupDetectionDomainId remain the same). However to retain maximum flexibility, Apama recommends that customers follow the industry standard practice of using JNDI names for queues and topics so that it is always possible to configure any necessary redirections to allow the same logical (JNDI) name to be used in different deployment environments, such as production and deployment (for dynamic as well as static receiver).

As there is no restriction on changing the connection factory or JNDI server details between restarts of a persistent correlator, by using the same JNDI names (or if necessary, queue and topic names) in all environments, but different isolated JMS and JNDI servers for production and testing, it is possible to avoid unintended interactions between the production and test environments while also keeping the two configurations very similar and allowing production data stores to be examined in the test environment if necessary.