Class StatelessJdbcListener

All Implemented Interfaces:
FrankElement, HasApplicationContext, HasName, HasPhysicalDestination, IConfigurable, IListener<Serializable>, IPeekableListener<Serializable>, IPullingListener<Serializable>, IScopeProvider, NameAware, TransactionAware, ConfigurableLifecycle, org.springframework.beans.factory.Aware, org.springframework.context.ApplicationContextAware, org.springframework.context.Lifecycle, org.springframework.context.Phased, org.springframework.context.SmartLifecycle

A JDBC Listener that does not maintain any processing-state in the table to which it listens. The listener will pick up the message-field, key field, message-id field, correlation-id and additional fields from the first record returned by the select-query.

This listener does not maintain any processing-state in the table, like the JdbcTableListener or MessageStoreListener do. To prevent messages from being picked up by multiple instances of the same listener, queries will always use SELECT .... FOR UPDATE to make sure the rows are locked.

In transactional Receivers this will keep the row locked for the entire duration of the pipeline, potentially stalling other processes. Because there is no state-change management, everything will happen in a single transaction.

To prevent the same message being picked up again after the pipeline completes, you should either remove it, or update it so that it no longer matches the SELECT conditions of the query. You can either:

NB: If the pipeline fails and was executed transactionally, the transaction will be rolled back and so any SQL statements that have deleted or updated the row will also be rolled back.

The setSelectQuery(String) and AbstractJdbcListener.setPeekQuery(String) will be automatically modified to be SELECT ... FOR UPDATE or SELECT ... FOR SHARE SKIP LOCKED queries. With some databases this means you cannot grouping queries or queries using COUNT(...), SUM(...) or similar statements.

This listener does not do any validation of the queries in configuration, or when opened. Any errors in your queries can result in a heavy load on the system as queries are retried in quick succession, so be careful with the configuration.
All the fields which you want to use and have configured as either key, message, message-id, correlation-id or additionalFields need to be added to the SELECT clause of your query with the exact same name.
If a field is missing or incorrectly spelled, it will either be silently dropped or may default to another value.