Class JdbcTransactionalStorage<S extends Serializable>

All Implemented Interfaces:
FrankElement, HasApplicationContext, HasName, HasPhysicalDestination, IConfigurable, IMessageBrowser<S>, IScopeProvider, ITransactionalStorage<S>, IXAEnabled, NameAware, ConfigurableLifecycle, org.springframework.beans.factory.Aware, org.springframework.context.ApplicationContextAware, org.springframework.context.Lifecycle, org.springframework.context.Phased, org.springframework.context.SmartLifecycle
Direct Known Subclasses:
DummyTransactionalStorage, MessageStoreSender

public class JdbcTransactionalStorage<S extends Serializable> extends JdbcTableMessageBrowser<S> implements ITransactionalStorage<S>
Implements a message log (JdbcMessageLog) or error store (JdbcErrorStorage) that uses database table IBISSTORE. A MessageStoreSender and MessageStoreListener pair implicitly includes a message log and an error store. If you have a MessageStoreSender and MessageStoreListener pair it is superfluous to add a JdbcMessageLog or JdbcErrorStorage within the same sender pipe or the same receiver.

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.

Storage structure is defined in /IAF_util/IAF_DatabaseChangelog.xml. If these database objects do not exist, the Frank!Framework will try to create them.

N.B. Note on using XA transactions: If transactions are used on Oracle, make sure that the database user can access the table SYS.DBA_PENDING_TRANSACTIONS. If not, transactions present when the server goes down cannot be properly recovered, resulting in exceptions like:
   The error code was XAER_RMERR. The exception stack trace follows: javax.transaction.xa.XAException
        at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:508)
   
Since:
4.1
Author:
Gerrit van Brakel, Jaco de Groot