| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WBIMB and multiple DBMS in a flow |
« View previous topic :: View next topic » |
| Author |
Message
|
| schroederms |
 Posted: Tue Sep 13, 2005 5:02 am Post subject: WBIMB and multiple DBMS in a flow |
 |
|
Disciple
Joined: 21 Jul 2003
Posts: 169
Location: IA
|
I've got a flow that I'm trying to test transaction rollbacks for. The flow is basically this.
INPUT NODE ==> COMPUTE to SELECT ROWS ===> COMPUTE to UPDATE of a SYBASE table from ENV variables ====> COMPUTE to UPDATE of a Oracle table from ENV variables.
The TRANSACTION property on the updates nodes is AUTOMATIC.
If I manually code a "THROW" in the ESQL in the last compute node both updates are rolled back. (THIS IS GOOD)
(FIRST ISSUE) If I wire the failure node of the "COMPUTE to UPDATE of a SYBASE table" it still rolls this update back as well. I knew it would rollback the transaction of the compute node that I actually coded the THROW in , but I thought once it hit a compute node with the failure node wired, the commit would happen there.
(SECOND ISSUE) If I take out the manually coded THROW and wire the output node of the last compute node that updates Oracle and put that message to a queue that is PUT DISABLED, the flow throws a exception stating the fact that the queue is PUT DISABLED, but the transactions are not rolled back from either DBMS.
Running on AIX version 5 CSD 5.
Any ideas ?
Thanks,
Mike |
|
| Back to top |
|
 |
| tillywern |
| Posted: Tue Sep 13, 2005 10:33 am Post subject: Managing Commit Points |
|
|
Centurion
Joined: 28 Jan 2003
Posts: 109
Location: Colorado
|
As we have technologies like WBIMB that make it easier to code it gets mroe and more difficult for us to manage or control underlying areas of the code like commit points.
Is your flow running under transaction control?
Have you validated the commit settings on your nodes? You may want to bring a particular database interaction out of the unit of work.
On your first issue. Commit boundary is at the flow level. Probably your flow is set, by default, to commit when it finishes all activity, usually a put to an outbound queue. Immediate commits can be achieved by setting properties on the node.
After much duress in this area we were able to create a setup which would allow us to log error messages to a database table. Of course this would have to be done outside the unit of work that did other database actions that were rolled back.
On your second issue. Interesting situation.. Are your messages persistent? You might try a throw off the failure terminal of the output node.
I hope this provides some help. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
