I know about two phase commit and my question is regarding the transaction boundries crossing multiple resources like DB, Mainframe, MQSeries to staffware and others.
Our scenario is EJB starts a transaction and call Oracle DB then calls CICS to do some commit and then calls DB2 and finally calls staffware to move the item from one staffware queue to another.
In other transactions the above four resources are used in different order.
Now can I use two phase commit in this circumstance. I am calling CICs using ECI and using a transaction name.
If say after calling ORacle, DB2 and finally calling CICS fails how can the trransaction manager does the rollback of cics trransactions?
Does this work of transaction manager or we ave to write a trransaction in CICS Please explain?
Hi , IS your transaction manager capable of having two phase commit with the resource managers such as oracle , cics and db2 ?
The reason i ask this question , a jta aware transaction manager can talk to jta compliant resource managers such as oracle , db2 but i am not sure about a resource manager availablity for cics . you might need to handle it in CICS and its safe . because not all eai products comes with transactional capability with legacy systems .
In one of my projects we used weblogic , tuxedo elink for IMS and CICS. elink has two phase commit feature with CICS but if application were to rely on elinks transactional capability and in future plan to move to another OLTP apart from tuxedo then application might fail as they relied on elink's transactional capability .
If you need to go with J2EE all road then try to use j2ee compliant transactional and resource managers .If you dont have or find suitable resource manager for CICS to talk to the transaction manager then handle them in CICS .
I've done two-phase work in one environment (CICS) as well, but not distributed. Are all of your connections XA compliant? I guess they must be if you're trying this.
Is "accessing the same resources in a different order" a red flag? If one transaction is holding a lock on A and trying to get B while another transaction is holding a lock on B and trying to get A you have a textbook deadlock.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi