| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Implementing Transactions in J2EE environments |
« View previous topic :: View next topic » |
| Author |
Message
|
| amenein |
 Posted: Fri Dec 03, 2004 10:45 pm Post subject: Implementing Transactions in J2EE environments |
 |
|
Newbie
Joined: 03 Dec 2004
Posts: 3
|
Hello Folks,
The environment we have is J2EE environment. The application communicates with MQWF using the Java APIs from a Session Bean.
The application has several resources that are required to participate in 2-phase commit transction. MQWF must participate in these 2-phase commit transactions. Currently the MQWF calls do not participate in the WebSphere Application Server transactions which produces malfunction behavior.
Don't put using the MQWF Java APIs as limitation, we can switch to any other possible solution such as sending XML messages using JMS for example.
Many thanks for your help.
_________________
Kind regards,
Ahmed Aboul-Enein |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sat Dec 04, 2004 5:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Can you specify source environment:
apps server
OS platform
J2EE (WAS) provider
Thanks  |
|
| Back to top |
|
|
| amenein |
| Posted: Sat Dec 04, 2004 10:11 pm Post subject: |
|
|
Newbie
Joined: 03 Dec 2004
Posts: 3
|
Hi fjb_saper,
Thanks for your relpy.
Application Server: WebSphere Application Server 5 or greater "no limitation to change the version"
OS: Currently Windows 2k Server with minor possibility to move to Unix AIX.
The application server connects to the MQWF Server 3.5 through MQWF Client using the provided Java APIs.
Many thanks for your help.
_________________
Kind regards,
Ahmed Aboul-Enein |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Dec 05, 2004 10:43 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You say you connect to MQWF client....
I imagine that what you really do is putting a message to a queue that is then picked up by WF.
Make sure the XA button is checked in your Websphere MQ JMS Queue Connection Factory. Make sure the method sending the message to the queue / parent method needing a 2 phase commit has an attribute of transaction required and uses a container transaction.
You are talking J2EE environment so I am assuming you are using JMS. If not please do so. (Using java manual)
You should have no trouble with a 2 phase commit as long as:
a) Web server and WMQ server are on the same machine or you are using the transactional client (additional $$)
b) The XA attribute is set on the qcf
c) the method spanning the 2 phase commit is marked with either transaction attributes
required
requires new
Enjoy |
|
| Back to top |
|
|
| hos |
| Posted: Mon Dec 06, 2004 12:31 am Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
Ahmed,
please keep in mind that the MQWF server also performs a two phase commit with MQ and DB (outside of J2EE). No MQWF API call (neither Java nor XML) participates on this transactions. What I'm saying is: you'll never be able to rollback a MQWF transaction initiated by the API in case of a bad return code. Using the API in a user defined J2EE transaction should work, though. In case of z/OS you would need to use the Native Java API SupportPack WA0C instead of the shipped Java API. |
|
| Back to top |
|
|
| amenein |
| Posted: Wed Dec 08, 2004 12:46 am Post subject: |
|
|
Newbie
Joined: 03 Dec 2004
Posts: 3
|
Thanks a lot for your help, fjb_saper and hos.
I am NOT using JMS currently. we use the Java API com.ibm.workflow.api.*.
I understand that I MUST move to JMS and use XML for calling MQWF to support 2-phase commit.
The obvious problematic scenario we currently have is: Within one transaction, the application updates CMPs then completes a work item.
When the transaction is being commited, only CMPs are involved currently in the transaction, if delayed CMP persistency throws exceptions, the work item complition call cannot be rolled back, while CMPs fails.
In business view, the process instance has moved to the next employee while the manadatory work, persisted using CMPs, is not there.
What I understand from hos is that, in the last example, if the complete call failed bacause of an error in MQWF server, the transaction manager in WAS will not be rolled back and the updated CMPs will be eventually persisted. Did I get you right, hos?
Many thanks folks.
Cheers.
_________________
Kind regards,
Ahmed Aboul-Enein |
|
| Back to top |
|
|
| sac |
| Posted: Thu Dec 09, 2004 11:24 pm Post subject: |
|
|
Apprentice
Joined: 10 Feb 2003
Posts: 44
|
Ahmed,
The way we implemented it in our project was that we were having all the tasks related to Workflow implemented in Action Handler class. So we first used to perform the DB updates using Stateless SB (CMP), and then when control returns back to Action handler class we used to perform the Work item checkin/checkout.
If any exception happens while performing the DB operation, workitem checkin/checkout won't be performed. if any exception happen while work item checkin/checkout, the DB update will get rolled back, since both the operations are under one try/catch block in Action class.
Except for the Process instance creation in Stateless bean, everything else was performed in Action class.
For the JMS implementation i feel that since communication is going to be aysnchronous in nature, so if any exception occurs, the message/exception will be rolledback only to the queue and not propogated to calling client. |
|
| 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
|
|
|
|
