Announcement Announcement Module
No announcement yet.
Message driven channel adapter starts transaction even though there is no message Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Message driven channel adapter starts transaction even though there is no message

    I am just wondering how the message driven channel adapter works. I am using Bitronix TM as a transaction manager and Spring Integration 2.0.3.

    I set up a message driven channel adapter to handle DLQ'Ed message for a certain condition. The DLQ messages are passed to a message queue. The message driven channel adapter has acknowledge 'transacted'. What I see in my log, I have continuous warning from the transaction manager that it is executing transaction with 0 enlisted resource, which according to Bitronix that seems like a bug or misconfiguration.

    I see that this is the chronological sequence:
    1. ActiveMQ adds consumer for destination queue
    2. bitronix starts transaction, begin transaction, end transaction, commit transaction.
    3. ActiveMQ removes consumer from the destination queue.

    My question is, why does the transaction starts even though there is no message in the MQ? And why does Bitronix warn about executing 0 enlisted resource?

    In my comprehension, on a message driven queue, transaction should only start when there is a message to be retrieved. But this behavior sounds like the channel adapter is polling all the time. I may have misunderstood the concept. Some lights in the dark please?

    Thanks in advance.

    Sorry, I missed reading between the lines in Spring Integration reference guide. Polling is actively invoked in Message Driven Channel Adapter , therefore the poller sub-element is not applicable. That explains why the transaction is called every time it's invoked since the acknowledge is set to transacted. Does that mean my transaction will always execute 0 enlisted resource when there's no messages or am I facing a misconfiguration warning or something?
    Last edited by fngaserin; May 26th, 2011, 12:00 AM.

  • #2
    SPR-7366 kind of answered my question

    Seems like this issue kinda answer my question.

    From Juergen Hoeller's comment:

    Interesting, I wasn't aware of that sort of local transaction timeout - we've just encountered that with JTA before. In any case, thanks for the analysis - as of Spring 3.0.4, DefaultMessageListenerContainer triggers a local Session commit even if no message has been received. This should be safe and is also consistent with our use of an external transaction manager (if specified), where we always commit as well - for a similar reason.

    This will be available in tonight's 3.0.4 snapshot. Please give it a try and let us know whether it works for you now...