Announcement Announcement Module
No announcement yet.
SI Aggregator and Transactions Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • SI Aggregator and Transactions


    I have a question regarding an aggregator and transactions. We use the Atomikos transaction manager which is capable of using XA transactions with WebSphere MQ. When an exception occurs in our SI flow, the message is rolled back correctly.
    Now we want to use an aggregator to collect 100 MQ messages and post them as 1 big message to another MQ queue. I do not want to use the JDBC Store to store messages in the aggregator. When we use the default in-memory store, when are messages committed from the queue ?
    Are they committed when they are put in the memory store, or when they are released from the message store ?

  • #2

    If you haven't understood aggregator by Manual, I recommend to take a look into its source code.

    1. It doesn't matter which type of Message Store you use
    2. In-memory Message Store isn't transactional
    3. Aggregator stores each incoming Message to the Message Store behind the Message Group based on correlation strategy
    4. After store Aggregator checks release strategy to determine is there reason to release group and send reply to the outbound-channel.

    So, you transactions work like this:
    - If release strategy returns 'false', transaction is commited immediately, just after Message is stored in the Message Store. So it is taken from MQ and (attention!) sits only in the memomy.
    - If release strategy returns 'true', the aggregator builds reply message from group and send it into outbound-channel, and if downstream flow is single-threaded and should be within MQ-read transaction, your '1 big' message will be placed in the another queue at the same transaction.

    As you see you'll get atomicity and robustness only on the last message in the sequence.
    All problems here are around transactional MQ-read only one message.
    In your case, if one of those 100 messages could not be stored in the aggregators MS, transactions for all others will be commited...

    And, of course, from other side, you should understand a durability problem around in-memory MS.

    Now I don't have good solution for you, but, I think, you've got now some point to start.

    Take care,