Jta + 2 phase commit

hello,
I'm trying to execute 2 inserts to tables in 2 different databases (version 9.2), using the JTA package.
Everything works fine, but when i execute the utx.commit (uts being a UserTransaction object) , i keep on getting the error :
javax.transaction.SystemException: Could not commit: error code 17002- for additional error code check Oracle log file
Just before the utx.commit, the utx.getStatus() gives ACTIVE.
I checked all the settings in data_sources.xml and orion-application.xml, and they are correct.
Someone any ideas plz ?
Grtz,
Chris

I found out that the commit-coordinator must be defined in the application.xml and not in the orion-application.xml, and the data source used for it should be defined in the global data-sources.xml (in the config dir), but now i'm still getting following error :
error in execute() : javax.transaction.SystemException: Could not commit: error code 29540- for additional error code check Oracle log file.
What oracle log file ? what code is it giving back ? Is it a ora-... or something else ? Where can i find more info ?
I already start the oc4j container with option
" -Ddatasource.verbose=true -Djdbc.connection.debug=true "
but it doesn't give me more info.
plz help !

Similar Messages

MDB (2-phase commit) behavior during abnormal JMS termination

Hello to everyone!
I plan to test the following scenario tomorrow (sort of a bug replication in our system).
Anyway, wanted to know in advance the expected behavior (just in case one of you already know
or have an experience related to this test). Thank you in advance.
Scenario:
I want to test/know the behavior of a 2-phase commit (2PC) MDB when JMS server abnormally exits
(say the process was killed).
Test flow:
start app server --> deploy 2pc-mdb --> send dummy data --> kill jms process --> restart jms process
1. will the connection be closed properly?
2. when jms server restarts, will the value of active consumer(count) doubled?
note: i think after mdb deployment, corresponding destination consumer count is 1.
the problem that occurred in our system was that the consumer count doubled after server restarted.
it seem like the previous connection was not closed when the jms server abnormally terminated.
any inputs will be greatly appreciated.
thanks and best regards.

You have to use TxDataSource for container managed tx or if you are using JTA (in
addition to ofcourse doing 2PC).
S
"Dale Olzer" <[email protected]> wrote:
>
Using weblogic 6.1 SP 4
I have a simple container managed Message Driven Bean. Using a destination
type
javax.jms.Queue.
When the onMessage method finishes the Message is still Pending on the
queue.
see the ejb-jar.xml below
<ejb-jar>
<enterprise-beans>
<message-driven>
<display-name>IvrMessageBean</display-name>
<ejb-name>IvrMsgBean</ejb-name>
<ejb-class>com.edocs.ps.ivr.IvrMsgBean</ejb-class>
<transaction-type>Container</transaction-type>
<acknowledge-mode>Auto-acknowledge</acknowledge-mode>
<message-driven-destination>
<destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
</message-driven>
</enterprise-beans>
</ejb-jar>
I noticed when I set a JDBC TX DataSource to 2 Phase Commit, the JMS
transaction
started commitig and nothing was left pending in the Queue.
Does 2PC have to be set in a DataSource for Container Managed MDB's to
work?

Two phase commit and bean managed transactions

To all the Transaction GURUS!
          Hi guys (-and gals).
          I've been doing J2EE for quite a while, but today was my first at
          XA-Transactions and Bean Managed Transactions.
          Why am I doing this?
          ====================
          Well I have to be able to controll the transactionalbehaviour of my
          bean
          during runtime, since some bean calls would cause a transactional
          overflow due to the stress they would cause to the system, whereas
          smaller bean calls need to run in one transaction.
          -> Therefore I need Bean Managed Transactions
          Since the bean does a call on two Database Connections it has to use a
          XA-Transaction.
          -> Therefore I need XA-Transactions.
          Abstract
          ========
          - I just can't get a User TransAction into the right Status it stays
          in 'STATUS_NO_TRANSACTION' all the time
          - Therefore the SQL Commands can be comitted 'java.sql.SQLException:
          Does not support SQL execution with no global transaction'
          - Therefore I can't do a rollback 'java.lang.IllegalStateException:
          Transaction does not exist'
          - Therefore I wrote this mail.
          I don't want to be a smart-"ass" writing such a detailed and indepth
          mail. I just would like to show that I tried, and would like to have
          some replies from you guys.
          Below are my configurations, code and logfiles.
          Thanx for taking your time and hope that the other people may learn
          something as well.
          cu
          Stefan
          Scenario
          ========
          used Software
          Bea Weblogic (WL) 6.0 SPx (not real sure which SP i have)
          Oracle 8.1.6 using the API-Version 8
          I configured the system as follows:
          (ofcourse I 'xxx'ed out all of the confidential data, sorry guys;-))
          excerpt from:
          config.xml
          <JDBCConnectionPool CapacityIncrement="5"
          DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="2"
          LoginDelaySeconds="1" MaxCapacity="5" Name="oraclePool"
          Properties="user=xxx;password=xxx;dll=ocijdbc8;protocol=thin"
          RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          TestTableName="languages" URL="jdbc:oracle:thin:@xxx:1521:xxx "/>
          
          <JDBCTxDataSource EnableTwoPhaseCommit="true"
          JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
          PoolName="oraclePool" Targets="fbsserver"/>
          
          <JDBCConnectionPool CapacityIncrement="5"
          DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
          LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
          Properties="user=xxx;password=xxx;server=xxx.xxx.xxx"
          RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          TestTableName="Users" SupportsLocalTransaction="true"/>
          
          <JDBCTxDataSource EnableTwoPhaseCommit="true"
          JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
          Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
          
          ejb-jar.xml
          <ejb-jar>
               <enterprise-beans>
                    <session>
                         <ejb-name>TPCTestBean</ejb-name>
          <home>de.sitewaerts.futuna.common.test.tpcbean.TPCHome</home>
          <remote>de.sitewaerts.futuna.common.test.tpcbean.TPC</remote>
          <ejb-class>de.sitewaerts.futuna.common.test.tpcbean.TPCBean</ejb-class>
                         <session-type>Stateless</session-type>
                         <transaction-type>Bean</transaction-type>
                    </session>
               </enterprise-beans>
               <assembly-descriptor/>
          </ejb-jar>
          
          weblogic-ejb-jar.xml
          <weblogic-ejb-jar>
               <weblogic-enterprise-bean>
                    <ejb-name>TPCTestBean</ejb-name>
                    <stateless-session-descriptor/>
                    <jndi-name>finstral/ejb/test_tpc</jndi-name>
               </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          
          BeanCode (from the implementingBeanClass:
          'de.sitewaerts.futuna.common.test.tpcbean.TPCBean')
          public void setupTables() throws RemoteException
          UserTransaction tx = getTransaction();
          //getTransaction calls: 'tx = sCtx.getUserTransaction()' and does
          some errorhandling
          log.info("Die Transaktion vor den Connections: "+tx.toString());
          //Sorry bout the German. You should get the Message though.
          log.info("Der Transaktionsstatus vor den Connections:
          "+transactionStatus(tx));
          Connection conSecurity = getConnection(DATASOURCE_SECURITY, tx);
          //gets a Connection via a DataSourceName from the JNDI tree
          Connection conContent = getConnection(DATASOURCE_CONTENT, tx);
          log.info("Die frische Connection conSecurity: "+conSecurity);
          log.info("Die frische Connection conContent: "+conContent);
          tearDownTable(conSecurity);
          //Does nothing special
          tearDownTable(conContent);
          log.info("Die Transaktion nach dem Teardown: "+tx.toString());
          log.info("Der Transaktionsstatus nach dem Teardown:
          "+transactionStatus(tx));
          Statement stmt = null;
          try
          stmt = conSecurity.createStatement();
          //Well its getting interesting now.....
          log.info("Die Transaktion vor dem createtable: "+tx.toString());
          log.info("Der Transaktionsstatus vor dem createtable:
          "+transactionStatus(tx));
          log.info("Die Connection conSecurity vor dem createtable:
          "+conSecurity);
          log.info("Die Connection conContent vor dem createtable:
          "+conContent);
          stmt.executeUpdate(CREATE_TABLE);
          //above is the row 91 -> throws: 'java.sql.SQLException: Does
          not support SQL execution with no global transaction'
          stmt.close();
          stmt = conContent.createStatement();
          stmt.executeUpdate(CREATE_TABLE);
          stmt.close();
          commitTransaction(tx);
          catch (SQLException sqle)
          log.error("Konnte kein table init machen", sqle);
          rollbackTransaction(tx);
          //The Code for this method is below
          throw new EJBException(sqle);
          finally
          closeConnection(conSecurity);
          closeConnection(conContent);
          protected void rollbackTransaction(UserTransaction tx)
          log.info("Der Transaktionsstatus vor dem Rollback:
          "+transactionStatus(tx));
          log.info("Die Transaktion vor dem Rollback: "+tx.toString());
          try
          tx.rollback();
          //above is row 200 -> throws: 'java.lang.IllegalStateException:
          Transaction does not exist'
          log.info("Der Transaktionsstatus nach dem Rollback:
          "+transactionStatus(tx));
          log.info("Die Transaktion nach dem Rollback: "+tx.toString());
          catch (Exception e)
          log.error("Konnte die Transaktion nicht backrollen.", e);
          throw new EJBException(e);
          Log Excerpt
          ===========
          INFO setupTables() (66) - Die Transaktion vor den Connections:
          [email protected]
          INFO setupTables() (67) - Der Transaktionsstatus vor den Connections:
          STATUS_NO_TRANSACTION
          INFO setupTables() (72) - Die frische Connection conSecurity:
          weblogic.jdbc.rmi.SerialConnection@7c6daa
          INFO setupTables() (73) - Die frische Connection conContent:
          weblogic.jdbc.rmi.SerialConnection@3b425
          INFO setupTables() (78) - Die Transaktion nach dem Teardown:
          [email protected]
          INFO setupTables() (79) - Der Transaktionsstatus nach dem Teardown:
          STATUS_NO_TRANSACTION
          INFO setupTables() (86) - Die Transaktion vor dem createtable:
          [email protected]
          INFO setupTables() (87) - Der Transaktionsstatus vor dem createtable:
          STATUS_NO_TRANSACTION
          INFO setupTables() (88) - Die Connection conSecurity vor dem
          createtable: weblogic.jdbc.rmi.SerialConnection@7c6daa
          INFO setupTables() (89) - Die Connection conContent vor dem
          createtable: weblogic.jdbc.rmi.SerialConnection@3b425
          ERROR setupTables() (101) - Konnte kein table init machen
          java.sql.SQLException: Does not support SQL execution with no global
          transaction
               at
          weblogic.jdbc.oci.xa.XAConnection.beforeExecute(XAConnection.java:137)
               at
          weblogic.jdbc.oci.xa.Statement.executeUpdate(Statement.java:112)
               at weblogic.jdbc.jta.Statement.executeUpdate(Statement.java:185)
               at
          weblogic.jdbc.rmi.internal.StatementImpl.executeUpdate(StatementImpl.jav
          a:42)
               at
          weblogic.jdbc.rmi.SerialStatement.executeUpdate(SerialStatement.java:54)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.jav
          a:91)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBean
          Impl.java:130)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCBe
          anEOImpl.java:64)
               at
          de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseCo
          mmitUnitTest.java:51)
               at
          org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTes
          tCase.java:297)
               at
          org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servle
          tTestCaller.java:148)
               at
          org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCal
          ler.java:199)
               at
          org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTes
          tRedirector.java:149)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
               at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.
          java:213)
               at
          weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServl
          etContext.java:1265)
               at
          weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.
          java:1631)
               at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
               at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          INFO rollbackTransaction() (196) - Der Transaktionsstatus vor dem
          Rollback: STATUS_NO_TRANSACTION
          INFO rollbackTransaction() (197) - Die Transaktion vor dem Rollback:
          [email protected]
          ERROR rollbackTransaction() (206) - Konnte die Transaktion nicht
          backrollen.
          java.lang.IllegalStateException: Transaction does not exist
               at
          weblogic.transaction.internal.TransactionManagerImpl.rollback(Transactio
          nManagerImpl.java:228)
               at
          weblogic.transaction.internal.TransactionManagerImpl.rollback(Transactio
          nManagerImpl.java:222)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBean.rollbackTransaction(TPC
          Bean.java:200)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.jav
          a:102)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBean
          Impl.java:130)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCBe
          anEOImpl.java:64)
               at
          de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseCo
          mmitUnitTest.java:51)
               at
          org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTes
          tCase.java:297)
               at
          org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servle
          tTestCaller.java:148)
               at
          org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCal
          ler.java:199)
               at
          org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTes
          tRedirector.java:149)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
               at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.
          java:213)
               at
          weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServl
          etContext.java:1265)
               at
          weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.
          java:1631)
               at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
               at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          CONCLUSION
          ==========
          I'm going nuts.
          I just don't get it.
          The transaction is the same. I don't change the Connection. I start
          the Transaction at the beginning before I do anything!
          Please guys help me out.
          Thx alot.
          Stefan "it's three o'clock in the morning, my girlfriend left me, and
          my only friend is that stupid linux pinguine" Siprell
          Software-Development
          <<<<<<<<<<<<<<<<<<<<<<<<<<<
          <sitewaerts> GmbH
          Hebelstraße 15
          D-76131 Karlsruhe
          Tel: +49 (721) 920 918 22
          Fax: +49 (721) 920 918 29
          http://www.sitewaerts.de
          >>>>>>>>>>>>>>>>>>>>>>>>>>>


Hi Priscilla
          (did you ever see the movie ? :-))
          Well I moved away from the idea of using bean managed transaction. I'll
          be using Container Managed Transactions. To modify the
          transactionalbehaviour I'll write proxymethods which have certain
          different containermanaged transaction properties, but which all call
          the same private methods.
          But it works! Here is my experience:
          - I was doing a DDL statement: I was trying to create new Tables, which
          is a definite "no-go"
          - pay careful attention to:
          http://edocs.bea.com/wls/docs60/jta/trxejb.html#1051405
                    and
          http://edocs.bea.com/wls/docs60/jta/trxejb.html#1051741
          and use these Settings for the Pool, don't ask me why, but it took me
          hours to find it out by myself:
               <JDBCConnectionPool CapacityIncrement="5"
          DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
          LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
          Properties="user=xxx; password=xxx; server=xxx.xxx.xxx"
          RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          TestTableName="Users" SupportsLocalTransaction="true"/>
          where as the server (shown as: xxx.xxx.xxx) is the TNS Name of the
          Oracle Driver.
          It works great.
          Another thing you guys might want to do is write a simple StatelessSB
          which does JDBC calls and two different database Connections.
          Then write a UnitTest which calls this bean a couple hundred times (with
          the same transaction). Have one test do clean writes, and another which
          causes some SQL-Exception (too long Data Columns, or likewise).
          Always count the entries and see if everything worked out. We're using
          this SetupConstruction to test new combinations of AS(sorry Priscilla) /
          Database / Db-Drivers to have a "standard test".
          I know my two cents were uncalled for, but it might save you some
          time.....
          thanx for your help
          Stefan
          -----Ursprüngliche Nachricht-----
          Von: Priscilla Fung [mailto:[email protected]]
          Bereitgestellt: Donnerstag, 2. August 2001 21:42
          Bereitgestellt in: transaction
          Unterhaltung: Two phase commit and bean managed transactions
          Betreff: Re: Two phase commit and bean managed transactions
          Hi Stefan,
          Looks like you have not actually begun a transaction by calling
          UserTransaction.begin(),
          so your setupTables method is really executing with no transaction
          context.
          Priscilla
          Stefan Siprell <[email protected]> wrote:
          >To all the Transaction GURUS!
          >
          >Hi guys (-and gals).
          >I've been doing J2EE for quite a while, but today was my first at
          >XA-Transactions and Bean Managed Transactions.
          >
          >Why am I doing this?
          >====================
          >Well I have to be able to controll the transactionalbehaviour of my
          >bean
          >during runtime, since some bean calls would cause a transactional
          >overflow due to the stress they would cause to the system, whereas
          >smaller bean calls need to run in one transaction.
          >-> Therefore I need Bean Managed Transactions
          >Since the bean does a call on two Database Connections it has to use
          >a
          >XA-Transaction.
          >-> Therefore I need XA-Transactions.
          >
          >Abstract
          >========
          >- I just can't get a User TransAction into the right Status it stays
          >in 'STATUS_NO_TRANSACTION' all the time
          >- Therefore the SQL Commands can be comitted 'java.sql.SQLException:
          >Does not support SQL execution with no global transaction'
          >- Therefore I can't do a rollback 'java.lang.IllegalStateException:
          >Transaction does not exist'
          >- Therefore I wrote this mail.
          >
          >I don't want to be a smart-"ass" writing such a detailed and indepth
          >mail. I just would like to show that I tried, and would like to have
          >some replies from you guys.
          >
          >Below are my configurations, code and logfiles.
          >
          >Thanx for taking your time and hope that the other people may learn
          >something as well.
          >
          >cu
          >
          >Stefan
          >
          >
          >Scenario
          >========
          >
          >used Software
          >-------------
          >Bea Weblogic (WL) 6.0 SPx (not real sure which SP i have)
          >Oracle 8.1.6 using the API-Version 8
          >
          >
          >I configured the system as follows:
          >(ofcourse I 'xxx'ed out all of the confidential data, sorry guys;-))
          >excerpt from:
          >
          >config.xml
          >----------
          ><JDBCConnectionPool CapacityIncrement="5"
          >DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="2"
          >LoginDelaySeconds="1" MaxCapacity="5" Name="oraclePool"
          >Properties="user=xxx;password=xxx;dll=ocijdbc8;protocol=thin"
          >RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          >TestTableName="languages" URL="jdbc:oracle:thin:@xxx:1521:xxx "/>
          >
          >
          >
          ><JDBCTxDataSource EnableTwoPhaseCommit="true"
          >JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
          >PoolName="oraclePool" Targets="fbsserver"/>
          >
          >
          >
          ><JDBCConnectionPool CapacityIncrement="5"
          >DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
          >LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
          >Properties="user=xxx;password=xxx;server=xxx.xxx.xxx"
          >RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          >TestTableName="Users" SupportsLocalTransaction="true"/>
          >
          >
          >
          ><JDBCTxDataSource EnableTwoPhaseCommit="true"
          >JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
          >Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
          >
          >
          >
          >
          >
          >ejb-jar.xml
          >-----------
          ><ejb-jar>
          >     <enterprise-beans>
          >          <session>
          >               <ejb-name>TPCTestBean</ejb-name>
          >
          ><home>de.sitewaerts.futuna.common.test.tpcbean.TPCHome</home>
          >
          ><remote>de.sitewaerts.futuna.common.test.tpcbean.TPC</remote>
          >
          ><ejb-class>de.sitewaerts.futuna.common.test.tpcbean.TPCBean</ejb-class>
          >               <session-type>Stateless</session-type>
          >               <transaction-type>Bean</transaction-type>
          >          </session>
          >     </enterprise-beans>
          >     <assembly-descriptor/>
          ></ejb-jar>
          >
          >
          >
          >weblogic-ejb-jar.xml
          >--------------------
          ><weblogic-ejb-jar>
          >     <weblogic-enterprise-bean>
          >          <ejb-name>TPCTestBean</ejb-name>
          >          <stateless-session-descriptor/>
          >          <jndi-name>finstral/ejb/test_tpc</jndi-name>
          >     </weblogic-enterprise-bean>
          ></weblogic-ejb-jar>
          >
          >
          >
          >BeanCode (from the implementingBeanClass:
          >'de.sitewaerts.futuna.common.test.tpcbean.TPCBean')
          >-----------------------------------------------------------------------
          >---------------------
          >
          > public void setupTables() throws RemoteException
          > {
          > UserTransaction tx = getTransaction();
          > //getTransaction calls: 'tx = sCtx.getUserTransaction()' and does
          >some errorhandling
          >
          > log.info("Die Transaktion vor den Connections: "+tx.toString());
          > //Sorry bout the German. You should get the Message though.
          > log.info("Der Transaktionsstatus vor den Connections:
          >"+transactionStatus(tx));
          >
          > Connection conSecurity = getConnection(DATASOURCE_SECURITY, tx);
          > //gets a Connection via a DataSourceName from the JNDI tree
          > Connection conContent = getConnection(DATASOURCE_CONTENT, tx);
          >
          > log.info("Die frische Connection conSecurity: "+conSecurity);
          > log.info("Die frische Connection conContent: "+conContent);
          >
          > tearDownTable(conSecurity);
          > //Does nothing special
          > tearDownTable(conContent);
          >
          > log.info("Die Transaktion nach dem Teardown: "+tx.toString());
          > log.info("Der Transaktionsstatus nach dem Teardown:
          >"+transactionStatus(tx));
          >
          > Statement stmt = null;
          > try
          > {
          > stmt = conSecurity.createStatement();
          > //Well its getting interesting now.....
          >
          > log.info("Die Transaktion vor dem createtable: "+tx.toString());
          > log.info("Der Transaktionsstatus vor dem createtable:
          >"+transactionStatus(tx));
          > log.info("Die Connection conSecurity vor dem createtable:
          >"+conSecurity);
          > log.info("Die Connection conContent vor dem createtable:
          >"+conContent);
          >
          > stmt.executeUpdate(CREATE_TABLE);
          > //above is the row 91 -> throws: 'java.sql.SQLException: Does
          >not support SQL execution with no global transaction'
          >
          > stmt.close();
          >
          > stmt = conContent.createStatement();
          > stmt.executeUpdate(CREATE_TABLE);
          > stmt.close();
          > commitTransaction(tx);
          > }
          > catch (SQLException sqle)
          > {
          > log.error("Konnte kein table init machen", sqle);
          > rollbackTransaction(tx);
          > //The Code for this method is below
          > throw new EJBException(sqle);
          > }
          > finally
          > {
          > closeConnection(conSecurity);
          > closeConnection(conContent);
          > }
          > }
          >
          > protected void rollbackTransaction(UserTransaction tx)
          > {
          > log.info("Der Transaktionsstatus vor dem Rollback:
          >"+transactionStatus(tx));
          > log.info("Die Transaktion vor dem Rollback: "+tx.toString());
          > try
          > {
          > tx.rollback();
          > //above is row 200 -> throws: 'java.lang.IllegalStateException:
          >Transaction does not exist'
          > log.info("Der Transaktionsstatus nach dem Rollback:
          >"+transactionStatus(tx));
          > log.info("Die Transaktion nach dem Rollback: "+tx.toString());
          > }
          > catch (Exception e)
          > {
          > log.error("Konnte die Transaktion nicht backrollen.", e);
          > throw new EJBException(e);
          > }
          > }
          >
          >Log Excerpt
          >===========
          >INFO setupTables() (66) - Die Transaktion vor den Connections:
          >[email protected]
          >INFO setupTables() (67) - Der Transaktionsstatus vor den Connections:
          >STATUS_NO_TRANSACTION
          >INFO setupTables() (72) - Die frische Connection conSecurity:
          >weblogic.jdbc.rmi.SerialConnection@7c6daa
          >INFO setupTables() (73) - Die frische Connection conContent:
          >weblogic.jdbc.rmi.SerialConnection@3b425
          >INFO setupTables() (78) - Die Transaktion nach dem Teardown:
          >[email protected]
          >INFO setupTables() (79) - Der Transaktionsstatus nach dem Teardown:
          >STATUS_NO_TRANSACTION
          >INFO setupTables() (86) - Die Transaktion vor dem createtable:
          >[email protected]
          >INFO setupTables() (87) - Der Transaktionsstatus vor dem createtable:
          >STATUS_NO_TRANSACTION
          >INFO setupTables() (88) - Die Connection conSecurity vor dem
          >createtable: weblogic.jdbc.rmi.SerialConnection@7c6daa
          >INFO setupTables() (89) - Die Connection conContent vor dem
          >createtable: weblogic.jdbc.rmi.SerialConnection@3b425
          >ERROR setupTables() (101) - Konnte kein table init machen
          >java.sql.SQLException: Does not support SQL execution with no global
          >transaction
          >     at
          >weblogic.jdbc.oci.xa.XAConnection.beforeExecute(XAConnection.java:137)
          >     at
          >weblogic.jdbc.oci.xa.Statement.executeUpdate(Statement.java:112)
          >     at weblogic.jdbc.jta.Statement.executeUpdate(Statement.java:185)
          >     at
          >weblogic.jdbc.rmi.internal.StatementImpl.executeUpdate(StatementImpl.ja
          v
          >a:42)
          >     at
          >weblogic.jdbc.rmi.SerialStatement.executeUpdate(SerialStatement.java:54
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.ja
          v
          >a:91)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBea
          n
          >Impl.java:130)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCB
          e
          >anEOImpl.java:64)
          >     at
          >de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseC
          o
          >mmitUnitTest.java:51)
          >     at
          >org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTe
          s
          >tCase.java:297)
          >     at
          >org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servl
          e
          >tTestCaller.java:148)
          >     at
          >org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCa
          l
          >ler.java:199)
          >     at
          >org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTe
          s
          >tRedirector.java:149)
          >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
          >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          >     at
          >weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl
          >java:213)
          >     at
          >weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServ
          l
          >etContext.java:1265)
          >     at
          >weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl
          >java:1631)
          >     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
          >     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          >INFO rollbackTransaction() (196) - Der Transaktionsstatus vor dem
          >Rollback: STATUS_NO_TRANSACTION
          >INFO rollbackTransaction() (197) - Die Transaktion vor dem Rollback:
          >[email protected]
          >ERROR rollbackTransaction() (206) - Konnte die Transaktion nicht
          >backrollen.
          >java.lang.IllegalStateException: Transaction does not exist
          >     at
          >weblogic.transaction.internal.TransactionManagerImpl.rollback(Transacti
          o
          >nManagerImpl.java:228)
          >     at
          >weblogic.transaction.internal.TransactionManagerImpl.rollback(Transacti
          o
          >nManagerImpl.java:222)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.rollbackTransaction(TP
          C
          >Bean.java:200)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.ja
          v
          >a:102)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBea
          n
          >Impl.java:130)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCB
          e
          >anEOImpl.java:64)
          >     at
          >de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseC
          o
          >mmitUnitTest.java:51)
          >     at
          >org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTe
          s
          >tCase.java:297)
          >     at
          >org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servl
          e
          >tTestCaller.java:148)
          >     at
          >org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCa
          l
          >ler.java:199)
          >     at
          >org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTe
          s
          >tRedirector.java:149)
          >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
          >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          >     at
          >weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl
          >java:213)
          >     at
          >weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServ
          l
          >etContext.java:1265)
          >     at
          >weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl
          >java:1631)
          >     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
          >     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          >
          >
          >CONCLUSION
          >==========
          >I'm going nuts.
          >I just don't get it.
          >The transaction is the same. I don't change the Connection. I start
          >the Transaction at the beginning before I do anything!
          >Please guys help me out.
          >Thx alot.
          >
          >Stefan "it's three o'clock in the morning, my girlfriend left me, and
          >my only friend is that stupid linux pinguine" Siprell
          >Software-Development
          ><<<<<<<<<<<<<<<<<<<<<<<<<<<
          ><sitewaerts> GmbH
          >Hebelstraße 15
          >D-76131 Karlsruhe
          >
          >Tel: +49 (721) 920 918 22
          >Fax: +49 (721) 920 918 29
          >http://www.sitewaerts.de
          >>>>>>>>>>>>>>>>>>>>>>>>>>>>
          >
          >
          >

Data-source.xml - BaseResourceException - two phase commit

Hi,
I am seeing the following exception.   Please let me know how to fix this.
thanks
Sunita
com.sap.engine.services.connector.exceptions.BaseResourceException: The resource "xxx" does not support two-phase commit and cannot be enlisted in the current transaction, because another non supporting two-phase commit resource is already enlisted for component "webContainer/applications/JavaEE/YY-TPRO/YYr-TPRO" in application "JavaEE/YY-TPRO". Only one of the enlisted resources is allowed to be non two-phase commit compliant.
I am using JDBC 1.x datasource, and the .xml looks like this:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE data-sources SYSTEM 'data-sources.dtd'>
<data-sources>
<application-name>JavaEE/yy-TPRO</application-name>
<data-source>
    <data-source-name>xxx</data-source-name>
    <alias>jdbc/xxyyDB/TPRO</alias>
    <driver-name>OracleThin</driver-name>
    <init-connections>1</init-connections>
    <max-connections>20</max-connections>
    <max-time-to-wait-connection>60</max-time-to-wait-connection>
    <sql-engine>vendor_sql</sql-engine>
    <jdbc-1.x>
      <driver-class-name>oracle.jdbc.driver.OracleDriver</driver-class-name>
      <url>jdbc:oracle:thin:@sol-mercury:1521:hermes</url>
      <user-name>abcd</user-name>
      <password>abcd</password>
    </jdbc-1.x>
</data-source>
</data-sources>

HI,
Thanks for the response, I already went through these threads.
My exception seems to be related to this - Problem with connection sharing if J2EE transaction is running
and suggested solutions seems to be:
The problem is caused when there is an inappropriate attempt to open a second connection in an active JTA transaction. There is either an attempt to get a second connection from an un-shareable non-XA DataSource or an attempt to get it from another non-XA DataSource. You have to:
●     Use no more than one connection from this data source while the JTA transaction is active or
●     Declare the data source as shareable, depending on your application logic.
Question is, How can I make data source as shareable??
This application worked fine in JBoss, weblogic and now we are trying to port it to NetWeaver.
Is any of the above options are configurable in data-sources.xml?
Thanks for your guidance and response.
Surekha

ADF Service Interface: two-phase commit issue for multiple data sources

In FusionApps, For a service interface we had to use two DataSource resources (in the ejb-jar.xml),
one is ApplicationServiceDBDS for SI and the other one is ApplicationDBDS(I don’t know the exact reason why this is needed, but when running the webservice, Framework was throwing an error asking for this) After adding these two, now(while running the webservice) we’re caught up with an error saying that unable to participate in two phase commit. I think this is because we added two dataSources, if we just use one dataSource everything is working fine.
Error message from app server:
"JDBC driver does not support XA, hence cannot be a participant in two-phase commit. To force this participation, set the GlobalTransactionsProtocol attribute to LoggingLastResource (recommended) or EmulateTwoPhaseCommit for the Data Source=ApplicationDB"
we have made the changes to ApplicationDB as said in the error message, but then the server is failing to start because of this.

Hi,
this is what the doc says - though not about two phase commit but transaction sharing:
"At runtime, the calling client and the ADF service may or may not participate in the same transaction, depending on the protocol used to invoke the service (either SOAP or RMI). Only the RMI protocol and a Java Transaction API (JTA) managed transaction support the option to call the service in the same transaction as the calling client."
When your application accesses a remote ADF Business Components service, each remote call is stateless, and the remote service will not participate in the same transaction as the business component that uses a service-enabled application module's service interface.
In the majority of the cases, calls to remote services will be informational in nature and will not make changes to remote objects. However, if you must use a remote service to make changes, then keep these points in mind:
An exception thrown by the remote service will cause the local transaction to fail.
If you successfully call a remote service that results in modifying data, and then subsequently your local transaction fails for any reason, then it is the responsibility of your error handling code to perform a compensating transaction against the remote service to "undo" the previous change made."
http://docs.oracle.com/cd/E23943_01/web.1111/b31974/bcextservices.htm
Frank

2 Phase Commit Global Transaction resolution question.

Hi All,
I hope this is the right place to ask this question.
I'm trying to figure out what generally happens after the JTA AbandonTimeout occurs.
Here is the scenario.
1. Transaction Manager sends Commit to Resource Managers 1 and 2.
2. Resource Manager 1 receives and processes commit. Resource Manager 2 doesn't receive commit.
3. Resource Manager 1 returns acknowledgement.
4. Transaction Manager times out and starts recovery process.
5. Resource Manager 2 session times out and is set to in-doubt.
6. Transaction Manager can never reconnect to Resource Manager 2, and the AbandonTimeout is reached.
7. Transaction Manager abandons RM2 transaction.
8. Does Transaction manager return an error for global transaction?
I'm guessing the application the Transaction Manager is working for has its own timeouts which would most likely be a smaller value than the abandon timeout. So the transaction would most likely timeout. I'm just trying to make sure that the Global Transaction is not sent back as complete at a later time if the abandon timeout is reached.
Any Thoughts?
Thanks,
Matt

Petr-
In article <avflf9$ccu$[email protected]>, Petr Bulanek wrote:
Hi Marc,
Well, what does it really mean that \'Kodo will not respect the
semantics of the 2-phase-commit protocol\'?Are you saying that Kodo may commit my changes even if the other datastore
decides to roll the transaction back at the last moment?
That if Kodo has difficulties to commit, it would not roolback the global
transaction and as a result the other datastores will commit?You are correct: we currently do not do anything special for 2 phase
commit at all.
I mean, this is quite important and would like to know exactly what to
expect so I can work around it.
Thank you,
Petr
P.S.
I \'think\' I saw the plan to fix this in 2.5.x. What is the planned
release date?It is in the milestone for 2.5. We can't make any committments on its
release date, but it will hopefully be out within 2 months.
Marc Prud\'hommeaux wrote:
Petr-
You can integrate Kodo\'s JDO transactions into the Application Server\'s
global transaction (which might also commit multiple other
transactions). The only issue is that Kodo will not respect the
semantics of the 2-phase-commit protocol.
We expect to have this issue resolved soon.
In article <avdri3$f2o$[email protected]>, Petr Bulanek wrote:
I have noticed that there is open bug (211) that refers to 2 phase commit
and I just curious what the exact problem is.
Does that imply that the current version (2.4) does not allow 2 phase
commit?
Let\'s say I need to integrate JDO into global transaction (managed by App
server) and I may need during that transaction update multiple databases.
It could be implemented via JDO (multiple PMFs) or it could be a
combination of JDO and JDBC/EJB happening during the same transaction.
Am I likely to hit a problem if I do that?
Thank you,
Petr
Marc Prud\'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com

Whats 2-phase commit for

hi guys
i am curious, why JTA invent the 2-phase commit?
whats it stand for? how we use it.
thanks alot

http://www.webopedia.com/TERM/T/two_phase_commit.html
http://www.sei.cmu.edu/str/descriptions/dtpc.html
or just google it.

Optimizing 2 Phase Commit

Assume that a JTA transaction involves an update to a single database.
I was wondering if WLS will optimize this to do a local transaction to that database
and not invoke 2 phase commit on the transaction.
If this is true it would mean that we could code all UserTransactions the same
way.

Yes, our TM includes the one-phase optimization. If there is only a
single resource in the transaction, we do not do a separate prepare
phase and instead just commit the tx. There's nothing you need to set
etc. It's all automatic.
-- Rob
Barry Fortune wrote:
Assume that a JTA transaction involves an update to a single database.
I was wondering if WLS will optimize this to do a local transaction to that database
and not invoke 2 phase commit on the transaction.
If this is true it would mean that we could code all UserTransactions the same
way.

Distributed transactions and 2-phase commit in a SAP Netweaver environment

Hello,
I am a Java architect., I don't know very much the SAP technologies. I tried to found on forums or technical papers if SAP does support distributed transactions and two-phase commit, it's not clear. I found something on SAP WAS but my project is using a SAP PI 7.0 and I cannot find anything on the subject.
My goal is to include a SAP server (via PI 7.0) in a distributed transaction handled by a J2EE ESB (Oracle, ex-BEA Aqualogic) based on XA capabilities.
Does anyone have experience or feedback on this topic ?
Thanks.

Hi,
Do you know this white paper ?
[Distributed Transaction and 2 phase commit|https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/3732d690-0201-0010-a993-b92aab79701f]
Regards,
Olivier

How to recover in a two phase commit ?

I am implementing a two phase commit with Oracle XA in Oracle 8.1.6. I am wondering how I can recover from failures occur between the PREPARE and the COMMIT stage. If I lose the database connection after the changes have been prepared, then I can't find a way to rollback or commit the changes.
Appreciate any helps.
Sam

The iPod OS takes care of where/how to store the files on the iPod and it has not done this. This is why you need to get the files off your iPod first.
My goal is to connect my iPod to my Mac, launch iTunes, and all of what's on my iPod displays in iTunes after single-clicking the iPod's icon in the Source pane of iTunes' window.
This is very, very simple. This is how iTunes works normally.
Since you now have the stuff from your iPod on your computer (using Ollie's iPod Extractor), load them into iTunes.
Sync them to the iPod. This will update the iPod database so all of the files are seen/identified correctly by the iPod.
Set the iPod prefs in iTunes to manually update.
Now you can delete the stuff on your computer and iTunes and view/edit/delete the stuff on the iPod using iTunes.
The outcome of using the utilities suggested in previous posts is that all of what's on my iPod gets copied to my Mac's hard drive (which is not what I'm trying to accomplish) and then that displays in iTunes' Library.
Only because the files on the iPod are not "useable" with the iPod or iTunes right now.
This is not something you will have to do everytime.
Once you get them on your computer, you can do the above steps and you will not have to use any utilities.
Just use iTunes.

Configuration of two-phase-commit in OC4J 10.1.2

Configuration of two-phase-commit in OC4J 10.1.2 in application with multiple modules
We have an application ear file consisting of ejb-modules (mdb and slsb) and two web-modules. We are using Oracle's advanced queueing for messaging and CMT (all ejb use the Required transaction attribute). We need different datasources (OrionCMTDataSource) including that for aq, so we need two-phase-commit. The web clients use ejbs and browse the messaging system. Our 'orion-application.xml' includes a commit-coordinator configuration, and the database is setup correctly. The configuration works fine for mdbs, when sending messages to the queues. When a client starts after messages have been sent and consumed by the mdbs, oc4j complains that no commit-coordinator is defined in 'server.xml'. If we start the client first, it can access the queues, but then the mdbs complain. It seems that the first one "gets" the commit-coordinator and the second one fails.
Some questions:
Why isn't the second client type using the commit-coordinator configuration of the "orion-application.xml"?
Is such scenario not supported by OC4J?
How can I setup the application correctly?
How do I configure commit-coordinator with different datasources to the same database? (Commit-Coordinator is also this database)

Take a look 'How to Use a Custom Serializer with Oracle Application Server Web Services' [1].
In your case, you should be looking at BeanMultiRefSerializer (org.apache.soap.encoding.soapenc), which will serialize your data using href and providing a way to deal with cycles.
All the best,
Eric
[1] http://www.oracle.com/technology/tech/webservices/htdocs/samples/serialize/index.html

Emulate Two-Phase Commit

HI,
<Mar 20, 2009 8:25:32 AM EDT> <Error> <HTTP> <BEA-101017> <[weblogic.servlet.internal.WebAppServletContext@1c1ac17 - appName
: 'lms-app', name: 'lms', context-path: '/lms'] Root cause of ServletException.
javax.ejb.EJBException: nested exception is: javax.ejb.TransactionRolledbackLocalException: EJB Exception: ; nested exception is: javax.ejb.EJBException:
nested exception is: javax.ejb.CreateException:
nested exception is: java.sql.SQLException: Connection has already been created in this tx context for pool named ejbDS. Illegal attempt to create connection from another pool: liveDS
I enabled Emulate Two-Phase Commit option for both the datasources ejbDS and liveDs. But still this error is coming in weblogic 9.2.2.
Can anybody suggest?
Thanks
Naveen

Hi Venki,
I have encountered the same issue for WebLogic 10.3.Speculating that you have fixed the error for 9.2, could you please provide your inputs on how to fix these kind of issues.
Thnks
Pavan

2 phase commit in java..!!!!!!!! VERY URGENT!!!!!!!!

Hi,
Can I implement 2 phase commit in a standalone java application ?
I access multiple databases with different connection objects in a single class in a single transaction. But how do I implement the 2 phase commit manually in a java standalone application.
Please note that I dont have any environment(like server, jndi etc.,) where i can deploy the datasources.
So pls let me know whether i can implement distributed transactions in this scenario.
This is very urgent.

There are two ways:
1. use an existing transaction monitor, either via an app server, or I think some, such as Tuxedo, can be used on their own, but even then you might need some elements of J2EE such as JNDI to use this. JBoss is a free app server that allows you to access its services, such as connection pooling and transaction monitoring, without having to rewrite your app as EJB or servlet based.
2. write your own.

Two Phase Commit on Slow Network

Can I implement two phase commit transaction using Windows 2000 Professional's Dial-Up Connection ? Where would I find information on this ? I connected two Windows 2000 Prof. PCs using Dial-Up Connection on Telephone line. Now if I try to ping service on other PC using TNSPING it gives me connection timed out, how should I tackle this issue ?

Hi Ioakim
Performing an atomic transaction(ACID) that spans a source system, BizTalk and then a different destination system is not possible. This is due to the nature of distributed transactions - it may not be practical to hold locks on resources(needed for atomic
transactions) that are spread across different networks. Given that there is no guarantee that the resources may be released in a reasonable amount of time, transactions in BizTalk can only be scoped to and from the BizTalk MessageBoxDb. Or in other words,
you can read a record to BizTalk transactionally and on the send side, send a message from BizTalk transactionally.
However, you can simulate/fake atomic transaction characteristics(although tricky) using compensation logic within BizTalk orchestrations. So, lets say you read+delete a record from SystemA into BizTalk, and that record has to be updated in SystemB.
If for some reason the insert to SystemB fails, you would have to write custom logic in a compensation block that then performs the reverse operation in SystemA - i.e., it inserts back the record in SystemA in this case. So, using compensating actions, it
is possible to ensure that all the systems involved are transactionally consistent at the end of the day.
There's an article from C.Young that discusses this in some detail-
http://geekswithblogs.net/cyoung/archive/2006/12/06/100424.aspx
Thanks
Arindam

SAP Transaction in Two phase Commit ?

Hi all,
When we make a connection to SAP system from .NET application using .NET connector, we can make calls to transactional BAPI/RFCs. But is there any way in which we can make SAP transaction take part in MS DTC (Microsoft Distributed Transaction Coordinator) transactions?
We want to implement a two phase commit and hence this question. Please let us know if you are aware of any mechanism using which we can implement a two phase commit.
The call scenario is described below:
TransactionScope
1.     SQL_StoredProc1();
2.     SQL_StoresProc2();
     10.           SAP_TransactionBAPI();
     11.          SQLStoredProcn();
      12.           SQLTransaction_Commit();
      13.      SAPTransaction_Commit();
Exception ()
SQLTransaction_Rollback();
SAPTransaction_Rollback();
In the above case all the statements have to be executed successfully or they have to be rolled back. Lets think of the situation where all the statements up to line 13 have been executed successfully, but there was a failure during the commit of SAP, and then we have to rollback the SQL transaction also which is already committed.
This situation can be handled if and only if SAP transaction manager follows XA transaction protocol and it can include itself in MSDTC. So that every transaction manager votes for the commit (it can be called half commit) if the transaction is successful otherwise all the transactions should be rolled back.
Can anybody tell me the way to include SAP transaction manager in MSDTC if it at all possible?

Hi Saket,
I did not understand much of your query but just wanted to know how are you making a connection to the backend here?
If using DataSources and if the datasource is configured directly in the EP server (using Visual Administrator), you have an option of the required 2-way commit.
The datasource takes care of it directly. Apart from this, the datasource will also take cre of the connection pooling.
Hope this helps.
Awaiting Reply.
Warm Regards,
Ritu

Jta + 2 phase commit

Similar Messages

Maybe you are looking for