Class JmsTransactionalStorage<S extends Serializable>

java.lang.Object
org.frankframework.jndi.JndiBase
org.frankframework.jms.JMSFacade
org.frankframework.jms.JmsMessageBrowser<S,javax.jms.ObjectMessage>
org.frankframework.jms.JmsTransactionalStorage<S>
All Implemented Interfaces:
HasPhysicalDestination, IConfigurable, IConfigurationAware, IMessageBrowser<S>, INamedObject, IScopeProvider, ITransactionalStorage<S>, IXAEnabled, org.springframework.beans.factory.Aware, org.springframework.context.ApplicationContextAware

public class JmsTransactionalStorage<S extends Serializable> extends JmsMessageBrowser<S,javax.jms.ObjectMessage> implements ITransactionalStorage<S>
Implements a message log (JmsMessageLog) or error store (JmsErrorStorage) that uses JMS technology.

Message log: A message log writes messages in persistent storage for logging purposes. When a message log appears in a receiver, it also ensures that the same message is only processed once, even if a related pushing listener receives the same message multiple times.

Error store: Appears in a receiver or sender pipe to store messages that could not be processed. Storing a message in the error store is the last resort of the Frank!Framework. Many types of listeners and senders offer a retry mechanism. Only if several tries have failed, then an optional transaction is not rolled back and the message is stored in the error store. Users can retry messages in an error store using the Frank!Console. When this is done, the message is processed in the same way as messages received from the original source.

How does a message log or error store see duplicate messages? The message log or error store always appears in combination with a sender or listener. This sender or listener determines a key based on the sent or received message. Messages with the same key are considered to be the same.
Since:
4.1
Author:
Gerrit van Brakel