Base class for listener container implementations which are based on polling.
Provides support for listener handling based on MessageConsumer,
optionally participating in externally managed transactions.
The underlying mechanism is based on standard JMS MessageConsumer handling,
which is perfectly compatible with both native JMS and JMS in a Java EE environment.
Neither the JMS MessageConsumer.setMessageListener facility nor the JMS
ServerSessionPool facility is required. A further advantage of this approach is
full control over the listening process, allowing for custom scaling and throttling
and of concurrent message processing (which is up to concrete subclasses).
Message reception and listener execution can automatically be wrapped
in transactions through passing a Spring
PlatformTransactionManager into the
"transactionManager" property. This will usually
be a JtaTransactionManager in a
Java EE environment, in combination with a JTA-aware JMS ConnectionFactory
obtained from JNDI (check your application server's documentation).
This base class does not assume any specific mechanism for asynchronous
execution of polling invokers. Check out DefaultMessageListenerContainer
for a concrete implementation which is based on Spring's
including dynamic scaling of concurrent consumers and automatic self recovery.
Set the transaction mode that is used when creating a JMS Session.
Default is "false".
Note that within a JTA transaction, the parameters passed to
create(Queue/Topic)Session(boolean transacted, int acknowledgeMode)
method are not taken into account. Depending on the Java EE transaction context,
the container makes its own decisions on these values. Analogously, these
parameters are not taken into account within a locally managed transaction
either, since the accessor operates on an existing JMS Session in this case.
Setting this flag to "true" will use a short local JMS transaction
when running outside of a managed transaction, and a synchronized local
JMS transaction in case of a managed transaction (other than an XA
transaction) being present. This has the effect of a local JMS
transaction being managed alongside the main transaction (which might
be a native JDBC transaction), with the JMS transaction committing
right after the main transaction.
Default is none, not performing any transactional wrapping.
If specified, this will usually be a Spring
JtaTransactionManager or one
of its subclasses, in combination with a JTA-aware ConnectionFactory that
this message listener container obtains its Connections from.
Note: Consider the use of local JMS transactions instead.
Simply switch the "sessionTransacted" flag
to "true" in order to use a locally transacted JMS Session for the entire
receive processing, including any Session operations performed by a
SessionAwareMessageListener (e.g. sending a response message). This
allows for fully synchronized Spring transactions based on local JMS
transactions, similar to what
JmsTransactionManager provides. Check
AbstractMessageListenerContainer's javadoc for
a discussion of transaction choices and message redelivery scenarios.
public void setReceiveTimeout(long receiveTimeout)
Set the timeout to use for receive calls, in milliseconds.
The default is 1000 ms, that is, 1 second.
NOTE: This value needs to be smaller than the transaction
timeout used by the transaction manager (in the appropriate unit,
of course). 0 indicates no timeout at all; however, this is only
feasible if not running within a transaction manager and generally
discouraged since such a listener container cannot cleanly shut down.
A negative value such as -1 indicates a no-wait receive operation.
This implementation checks whether the Session is externally synchronized.
In this case, the Session is not locally transacted, despite the listener
container's "sessionTransacted" flag being set to "true".
Template method that gets called right when a new message has been received,
before attempting to process it. Allows subclasses to react to the event
of an actual incoming message, for example adapting their consumer count.
Template method that gets called when no message has been received,
before returning to the receive loop again. Allows subclasses to react to
the event of no incoming message, for example marking the invoker as idle.