| Author |
Message
|
| shilpadesai |
 Posted: Mon May 20, 2002 11:58 am Post subject: How to rollback a transaction .. |
 |
|
Novice
Joined: 09 May 2002
Posts: 12
|
Friends this is my requirement and I would like to know whether this is possible or not.
One of my front-end application PUTs message in a queue(X) which is an Input node for a MQSI Workflow. The Output node is again a MQ Queue(Y). A remote applicaton do a GET's on this Output MQ queue(Y) using SYNC_POINT_ON.
Under this scenario if the remote application rolls back, I know my message is going to remain in output queue(Y). My question is can I rollback the flow under this corcumstances ?
How can I tell my front-end application to roll back when:
1. this MQ operation is a local transaction.
2. this MQ operation is the part of global transaction.
Thanks for your help.
Shilpa |
|
| Back to top |
|
 |
| kirani |
| Posted: Mon May 20, 2002 1:36 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Can you tell us more about the applications and message flow. On which platform they reside and are they doing any DB updates?
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| shilpadesai |
| Posted: Mon May 20, 2002 1:57 pm Post subject: |
|
|
Novice
Joined: 09 May 2002
Posts: 12
|
Thanks for the reply.
My front-end client is J2EE based app using Websphere 4.0 running on AIX 4.3. We are using JMS to access the Queues on MQSeries 5.2.
The broker is MQSI 2.1 also running on AIX 4.3. In my flow I have a database node which do some select/update call to a DB2 database 7.1 to add more data to message and a compute node.
Hope this information helps.
Shilpa Desai. |
|
| Back to top |
|
|
| kirani |
| Posted: Mon May 20, 2002 3:39 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
I don't have much knowledge in this area but this is what I think,
You can use an external sync point/transaction coordinator (such as Websphere Application Server EE), which coordinates your transactions. Your queue managers participate in this transaction by acting as resource managers.
Since you are doing DB updates in your message flow, I don't think this will work for you. In WMQI, you have to configure your queue manager to act as a transaction coordinator. i.e. your broker queue manager will coordinate transactions between database and MQ.
I don't think you can have more than one transaction coordinator.
Guys correct me if I am talking rubbish! I am sure someone out there can give more explanation on this.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| shilpadesai |
| Posted: Tue May 21, 2002 6:41 am Post subject: |
|
|
Novice
Joined: 09 May 2002
Posts: 12
|
Thanks kiran,
Let me try to rephrase my question:
On Broker Queue Manager:
1. A front-end application Put's the message in a Local Queue.
2. The Local queue is attached to an Input Node of the Flow
3. Flow is MqInput-->Database Node-->Compute Node -->MqOutput
4 Database node do some Select/Update in database DB2 7.1
5. MqOutput is a remote queue on a remote queue manager.
On Remote Queue Manager on OS/390:
1. A CICS application reads the queue using SYNCPOINT_OPTION_ON.
2. If CICS transaction fails message remains on the queue. What to do now ??
I need to do two thing.
1. Rollback the work done at Database Node.
2. Inform the front-end application that transaction has failed.
Does any one has encountered design issue like this?
I will appreciate any other alternative design suggestion.
Regards,
Shilpa |
|
| Back to top |
|
|
| CHERIANV |
| Posted: Wed May 22, 2002 5:15 pm Post subject: |
|
|
Apprentice
Joined: 15 Feb 2002
Posts: 43
Location: New York
|
| shilpadesai wrote: |
Thanks kiran,
Let me try to rephrase my question:
On Broker Queue Manager:
1. A front-end application Put's the message in a Local Queue.
2. The Local queue is attached to an Input Node of the Flow
3. Flow is MqInput-->Database Node-->Compute Node -->MqOutput
4 Database node do some Select/Update in database DB2 7.1
5. MqOutput is a remote queue on a remote queue manager.
On Remote Queue Manager on OS/390:
1. A CICS application reads the queue using SYNCPOINT_OPTION_ON.
2. If CICS transaction fails message remains on the queue. What to do now ??
I need to do two thing.
1. Rollback the work done at Database Node.
2. Inform the front-end application that transaction has failed.
Does any one has encountered design issue like this?
I will appreciate any other alternative design suggestion.
Regards,
Shilpa |
Hi,
What exactly are you using WMQI for ? Is it for data transformation or enrichment ? Also, what kind of information are you updating with a Database node ? I was thinking -
a.) Can you design it as a REQUEST / REPLY scenario from your front-end application to your host application and have the CICS trans. on the host send back a REPLY on success.
b.) In WMQI, you may have to co-ordinate your ROLLBACK based on successful / unsuccessful REPLY.
Not sure of your applcation though to see if it would fit in. |
|
| Back to top |
|
|
| Cliff |
| Posted: Thu May 23, 2002 6:57 am Post subject: |
|
|
Centurion
Joined: 27 Jun 2001
Posts: 145
Location: Wiltshire
|
Shilpa,
you have 3 completely distinct Units Of Work here, so no, the failure of the CICS transaction cannot cause rollback of an already committed UOW.
The message which caused the CICS txn to abend is known as a poison message. Assuming your CICS app handles poison messages correctly (checking the backout count against the backout threshold, etc.), the requeued message could be input to another message flow which does a compensating update to reverse the earlier one. You've also got the possibility of using the SendMail plug-in, too.
Regards,
Cliff |
|
| Back to top |
|
|
| suneelsh |
| Posted: Fri May 24, 2002 9:48 am Post subject: |
|
|
Acolyte
Joined: 13 Apr 2002
Posts: 69
Location: Pune,India
|
In this situation as said earlier it is not possible to roll back what has already been committed as cliff rightly put it as distinct unit of work.
this is a design issue..so you probably need to have a diff design. cherainv
what exactly where you talking about request-reply scenario? you mean using aggregate nodes? even if you do a request reply type...you have already commited to the db which becomes one unit of work. so i dont think this will work..unless like i said before you have to change the design. |
|
| Back to top |
|
|
| CHERIANV |
| Posted: Sat May 25, 2002 4:11 pm Post subject: |
|
|
Apprentice
Joined: 15 Feb 2002
Posts: 43
Location: New York
|
| What I meant as a REQUESt /REPLY sceanario is not just the WMQI piece of unit of work. I very well know that there are 3 distinct units of works and that there needs to be an end to end design change. The front-end trans. (the first unit of work) can send an MQSeries message as a REQUEST all the way expecting a REPLY from the host. The CICS trans.(the thrird unit of work) can send a REPLY whether on success or failure. The WMQI unit of work is what I am not sure of and i was wondering if the comitted WMQI unit of work can be reversed in case of a unsuccessful REPLY so that front-end trans. knows it was unsuccessful. |
|
| Back to top |
|
|
|
|
