Posted: Mon Apr 09, 2018 7:51 am Post subject: Unexpected Publication Node Transaction Behaviour
Newbie
Joined: 09 Apr 2018 Posts: 3
Hi,
I've been putting together some examples for a client as a learning tool regarding Transactions/Unit Of Work using various input types and outputs.
I've come across what I consider unexpected behaviour from a flow containing a Publication node.
(Publication does support Transactions by setting Properties.Transactional = true/false - APAR IC68354 makes that clear)
I am, under certain circumstances, getting uncommitted messages from a publication continuing to show on a subscriber queue after completion of the flow - Rollback or Complete normally on Catch terminal.
The Example flow is configured as below.
The flow accepts MQInput and Out terminal is connected to a FlowOrder node, the first leg of which routes to a compute node which propagates two msgs to a Publication node each with different Topic/Subscription set ups to deliver to separate queues.
One msg is configured with Properties.Transactional=true the other false.
Additionally the Compute node writes two entries to a DB table. Compute->Transaction=Automatic
The Second leg of the FlowOrder node connects to a compute node which inserts a 30 second delay so user can peek at the status of subscribed queues (e.g. to see Uncommitted Msgs) before a Throw node generates an error.
The MQInput Catch terminal has a filter node that queries the input message and either routes to another Throw node (intended to show Rollback behaviour) or to a Compute node that simply returns True - Flow completing normally.
Now my problem.
Scenario 1 - MQInput property Advanced-->Transaction Mode = No
If NO exception is thrown on the Catch path then
1) Database inserts commit
2) The Non-Transactional Publication is delivered
3) The Transactional=true publication remains showing as an Uncommitted message on the subscriber queue.
If an exception IS thrown on Catch path then
1) Database inserts are rolled back,
2) Non-Transactional Publication is delivered
3) Transactional=true publication remains showing as an Uncommitted message on the subscriber queue.
I don't expect IIB to leave Uncomitted Transactions when a flow has completed its processing.
On the flip side:
Scenario 2 - MQInput property Advanced-->Transaction Mode = Yes
If no throw generated on Catch path then
1) Database inserts commit
2) The Non-Transactional Publication is delivered
3) The Transactional=true publication is delivered/committed to subscriber queue.
If throw IS generated on Catch path then
1) Database inserts are rolled back,
2) Non-Transactional Publication is delivered
3) Transactional=true publication is rolled back from the subscriber queue.
4) Because MQInput Failure terminal is not connected the input message is placed on defined Back Out queue
This is consistent with what I expect given my understanding of IIB
Am I misunderstanding something fundamental or is this outstanding uncommitted messages in scenario 1 an IIB issue that I should report?
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum