CMDTUX_CAT:423: WARN: One-phase commit - xa_commit returned -7

Hi All
After fail over we get:
CMDTUX_CAT:423: WARN: One-phase commit - xa_commit returned -7.
Some information:
The related TMS_ORACLE is serviceing corba object.
OS: Solaris
Tuxedo 8.1
there was no activity on this object this object was idle prior to the fail over. (after restart)
Thanks
Tech Sgin

Hi,
Transactions should not be able to get into a "weird state" where they can't be recovered. Also, although it's not necessarily a problem, getting a one phase commit error means that there was only one XA resource involved in the transaction. If by design you know that only one resource manager is going to be involved in the transaction, using a local RM transaction instead of an XA transaction is going to be significantly more efficient. Just make sure you don't try to mix local transactions with XA transactions as that will not work.
Regards,
Todd Little,
Oracle Tuxedo Chief Architect

Similar Messages

  • Scope of one phase commit optimization?

    Hello,
    I am unclear about the scope across which Tuxedo XA can optimize the commit to a one phase commit when there is only a single resource involved.
    Is it just the process?
    Or is it the group (same TM)?
    Based on the XA specification, it is the connection that matters. The one phase commit is only possible if a single connection is involved.
    However, in the Tuxedo case, the Transaction Manager is shared amongst all the processes in a group. Therefore, the Transaction Manager could be aware that only one Resource Manager is involved, even when the transaction spans multiple processes (within the group). Thus from the TM perspective, a one phase commit would be possible. But then again the Resource Manager would have to support that too.
    The context for this is Tuxedo 11, ATMI, XA and Oracle 11g. Some transactions use /Q and DB (requiring XA and two phase commit), other transactions only affect the DB.
    Thanks...
    Roger

    Hi Roger,
    I'm not sure where the idea that one-phase commit is "only possible if a single connection is involved."? Here is the description of the one phase commit optimization from the XA specification:
    "One-phase Commit
    A TM can use one-phase commit if it knows that there is only one RM anywhere in
    the DTP system that is making changes to shared resources. In this optimisation,
    the TM makes its Phase 2 commit request without having made a Phase 1 prepare
    request. Since the RM decides the outcome of the transaction branch and forgets
    about the transaction branch before returning to the TM, there is no need for the TM
    to record stably these global transactions and, in some failure cases, the TM may not
    know the outcome."
    The TM can also get back read-only from an RM on prepare and use that to decide to perform a one-phase commit if there had only been one other RM involved.
    IIRC Tuxedo decides to do a one-phase commit if there is only one group involved in the transaction. So if you have two groups accessing the database, I don't believe Tuxedo will perform a one-phase commit, even if the two groups are connected to the same RM.
    Regards,
    Todd Little
    Oracle Tuxedo Chief Architect

  • One phase commit optimization with AQ as Foreign JMS Provider?

    Hello,
    we currently use Weblogic JMS and Oracle DB in our server. This requires XA and the two phase commit.
    We are considering to switch from Weblogic JMS to Oracle AQ. The main reason is to move persistence from files to the DB (which is RAC). We could use JDBC persistence, but we think AQ will be more efficient and flexible.
    We also hope that using AQ will allow WLS to make use of the one phase commit optimization in XA (when only one resource manager is involved). But I am wondering if the extra abstraction of the Foreign JMS Provider prevents that optimization.
    Anybody know? Have tried this?
    Thanks...
    Roger

    This might be of help to you. https://xa-compliant-oracleaq.projects.dev2dev.bea.com
              In this case, whenever the MDB polls on the bound QCF(This is a Referenceable Object), WebLogic calls the ObjectFactory class and recreates the QCF for the MDB. I think you can take a similar approach. Mind you will have to implement the Referenceable interface for this. This way, you won't have to re-run your startup class.
              cheers !
              Dips

  • 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 "/>
              <!-- Since this is our Main Datasource I would not like to use a XA
              Transaction due to performance Issues
              and the TxDataSource:
              -->
              <JDBCTxDataSource EnableTwoPhaseCommit="true"
              JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
              PoolName="oraclePool" Targets="fbsserver"/>
              <!-- no comment required -I hope.
              Next comes the "special" Pool
              -->
              <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"/>
              <!-- Well since there can only be one none XARessourceManager involved
              in a 2PC
              (keyword: Two Phase Commit) I will have to use a XACapable Driver for
              the other
              Datasource. Due to all the bugs in the oracle.xxx driver. I'll be
              using the jdriver for oci.
              I activated 'SupportsLocalTransaction' hoping it would solve my
              problem - without effect. I just left in there now, since it made
              sense me. Not?
              Again the TxDataSource:
              -->
              <JDBCTxDataSource EnableTwoPhaseCommit="true"
              JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
              Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
              <!-- The System starts right up and can locate the test tables and
              everything. So I think all of this stuff is working here -->
              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>
              <!-- Originally I had the assembly-descriptor full of transaction
              requirements. I thought since
              the bean is handling all of the transaction stuff itself, it might get
              confused by the 'container-transaction'
              properties, and deleted them. Do I need them anyway?-->
              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>
              <!-- Nothing I have to explain here -->
              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 "/>
              >
              ><!-- Since this is our Main Datasource I would not like to use a XA
              >Transaction due to performance Issues
              >and the TxDataSource:
              >-->
              >
              ><JDBCTxDataSource EnableTwoPhaseCommit="true"
              >JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
              >PoolName="oraclePool" Targets="fbsserver"/>
              >
              ><!-- no comment required -I hope.
              >Next comes the "special" Pool
              >-->
              >
              ><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"/>
              >
              ><!-- Well since there can only be one none XARessourceManager involved
              >in a 2PC
              >(keyword: Two Phase Commit) I will have to use a XACapable Driver for
              >the other
              >Datasource. Due to all the bugs in the oracle.xxx driver. I'll be
              >using the jdriver for oci.
              >I activated 'SupportsLocalTransaction' hoping it would solve my
              >problem - without effect. I just left in there now, since it made
              >sense me. Not?
              >Again the TxDataSource:
              >-->
              >
              ><JDBCTxDataSource EnableTwoPhaseCommit="true"
              >JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
              >Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
              >
              ><!-- The System starts right up and can locate the test tables and
              >everything. So I think all of this stuff is working here -->
              >
              >
              >
              >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>
              >
              ><!-- Originally I had the assembly-descriptor full of transaction
              >requirements. I thought since
              >the bean is handling all of the transaction stuff itself, it might get
              >confused by the 'container-transaction'
              >properties, and deleted them. Do I need them anyway?-->
              >
              >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>
              >
              ><!-- Nothing I have to explain here -->
              >
              >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
              >>>>>>>>>>>>>>>>>>>>>>>>>>>>
              >
              >
              >
              

  • 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

  • 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:
    &#9679;     Use no more than one connection from this data source while the JTA transaction is active or
    &#9679;     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

  • How to enable 2 phase commit in oracle11g(for distributed oracle databases)

    Hi All,
    We have three oracle servers(11g) and we need to update the data from one server to remaining servers. Want to know, is "two phase commit" automaticly enabled/installed in 11g or we need to enable it. If we need to enable it then what are the all steps required for the same.
    Thanks & Regards
    Ravi

    It is always very nice to see people think they are so unique their question has not already been answered in the documentation.
    Yes, two phase commit is enabled.
    No, depending on what you want, automatically updating records from one server to other servers is likely a very bad idea, as Oracle has documented facilities for that.
    You have amongst others
    - Materialized views
    - Oracle Streams
    Those solutions definitely scale much better as your approach, as they are asynchronous. In your approach the master server will slow down as a result of updating slaves.
    In distributed databases 'push' approaches are to be avoided and 'pull' approaches to be preferred. Which is exactly what materialized views and Streams do.
    Sybrand Bakker
    Senior Oracle DBA

  • Weblogic Two Phase commit

    Dears,
    we are facing slowness problem while migration application from weblogic 7 to weblogic 11g.
    Our Application use EJB 2.1 CMP and oracle database
    In web-logic 7 we use global transaction and emulate two phase commit .Our application works fine
    If we set global transaction as last logging resource or Emulate two phase commit in weblogic 11g we found so much slowness in the application.
    Kindly help me in this regard

    Hi,
              Jolt is just a Java client API for Tuxedo services. Typically, Jolt is
              used by a client to invoke a Tuxedo service. From what I could gather
              from your post, you are probably doing some JDBC work and then calling
              out to a Tuxedo service and want the work done with the JDBC/XA driver
              and the database work done by the Tuxedo service to be comitted/aborted
              transactionally? Is this correct?
              If so, then you probably want to look at the JET API (essentially Jolt
              without the need for a JSL/JSH) for invoking Tuxedo services directly
              (instead of through the JSH) from a WLE Java Server. It should be fully
              capable of doing what I have described above.
              Hope this helps,
              Robert
              Hwa Min Tan wrote:
              > I have read that the WLE 5.1 supports the Open XA standard for
              > two-phase (distributed) commits.
              > However, I have been unable to find any documentation / code
              > samples that demonstrates that JOLT is also able to perform
              > two-phase commits, even though its architecture is
              > inherently Tuxedo.
              > We'd like to use two-phase commit on two separate databases
              > (one connected by Jolt and another using the WLE JDBC/XA driver.
              >
              > Does Jolt support two-phase commit and the Open XA standard?
              >
              > Many thanks for your help,
              >
              > Hwa Min
              

  • 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

  • What is two phase commit in Forms?

    Hi
    Could any one tell me,
    what is two phase commit in Forms?
    Cyp

    Hi,
    two phase commit is a database feature that ensures data consistency.
    "Oracle's two-phase commit mechanism guarantees that, a distributed transaction will either commit on all involved nodes or roll back on all involved nodes."
    Frank

  • Is the 2-phase commit 100% reliable?

    Could there be a situation where there could be partial commits?
    Is it 100% accurate?
    Becuase we are thinking about using Oracle Transparent Gateway which has the 2PC mechanism.

    Well, there are cases when transactions get in doubt, and one has to do the manual recovery in two phase commit.
    Normally, ORA-02050 or ORA-02053 messages are received by the application in that case.
    You can check dba_2pc_pending for more help.
    regards

  • 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

Maybe you are looking for