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 J2EE 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
J2EE enviroment, in combination with a JTA-aware JMS ConnectionFactory obtained
from JNDI (check your J2EE 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
TaskExecutor abstraction,
including dynamic scaling of concurrent consumers and automatic self recovery.

AbstractPollingMessageListenerContainer

Method Detail

setSessionTransacted

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 J2EE 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. The latter 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).
Alternatively, a JmsTransactionManager
may be used for fully synchronized Spring transactions based on local JMS
transactions. Check AbstractMessageListenerContainer's javadoc for
a discussion of transaction choices and message redelivery scenarios.

setReceiveTimeout

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). -1 indicates no timeout at all; however, this is only
feasible if not running within a transaction manager.

isSessionLocallyTransacted

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".

messageReceived

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.

Parameters:

invoker - the invoker object (passed through)

session - the receiving JMS Session

noMessageReceived

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.