Commit crashes on bdbxml transaction

Hi,
I'm trying to perform a simple transaction for my xmlcontainer, but everytime i try to commit my transactions, my program crashes, it goes to the dbgheap.c then says that i have an unhandled exception. Here's my snippet:
int mySample()
String theContainer = "name";
String path2DbEnv = ".";
DbEnv env(0);
env.set_cachesize(0, 64*1024*1024, 1);
env.open(path2DbEnv.c_str(),
DB_INIT_MPOOL | DB_CREATE | DB_INIT_LOCK |
DB_INIT_LOG | DB_INIT_TXN, 0);
XmlManager mgr(&env);
XmlTransaction containerTxn = mgr.createTransaction();
XmlContainer container = mgr.createContainer(containerTxn, theContainer);
containerTxn.commit();
return 0;
// i just removed the try catch stuff, but other than that, what did i do wrong? did i miss something?
thanks,
Chesca

Hi,
I modified your code to get it to run. I am not seeing the exception. Note that if you use createContainer and the container already exists, an exception is thrown.
Try the following, and if that still causes an error, see if you can get an error message from the exception and a stack trace.
Here is what worked for me:
Ron
int test1 ()
std::string theContainer = "name";
std::string path2DbEnv = ".";
try
DbEnv env(0);
env.set_cachesize(0, 64*1024*1024, 1);
env.open(path2DbEnv.c_str(),
DB_INIT_MPOOL | DB_CREATE | DB_INIT_LOCK |
DB_INIT_LOG | DB_INIT_TXN | DB_RECOVER, 0);
XmlManager mgr(&env);
XmlTransaction containerTxn = mgr.createTransaction();
XmlContainer container = mgr.openContainer(containerTxn, theContainer, DB_CREATE);
containerTxn.commit();
container.close();
env.close(0);
std::cerr << "Success! ";
catch(std::exception &e) {
          std::cerr << "Exception. ";
          std::cerr << e.what() << "\n";
          exit( -1 );
return 0;
}

Similar Messages

  • 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
              >>>>>>>>>>>>>>>>>>>>>>>>>>>>
              >
              >
              >
              

  • Java.sql.SQLException: You cannot commit during a managed transaction!

    Hi all,
    I'm just trying to get the tutorial Car EJP app to work with Jboss 3.2.1
    When creating a new car record by calling the car.edit() method it reaches
    the line
    pm.makePersistent (car);
    and then throws the exception
    com.solarmetric.kodo.runtime.FatalDataStoreException:
    com.solarmetric.kodo.runtime.FatalDataStoreException:
    java.sql.SQLException: You cannot commit during a managed transaction!
    [code=0;state=null]
    When checking the jboss log, it is clear that kodo is trying to commit the
    sequence update :
    at
    org.jboss.resource.adapter.jdbc.WrappedConnection.commit(WrappedConnection.java:477)
    at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.commit(SQLExecutionManagerImpl.java:783)
    at
    com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory.updateSequence(DBSequenceFactory.java:267)
    at
    com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory.getNext(DBSequenceFactory.java:111)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.newDataStoreId(JDBCStoreManager.java:598)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.makePersistentFilter(PersistenceManagerImpl.java:1418)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.makePersistent(PersistenceManagerImpl.java:1348)
    at com.titan.kodojdotest.ejb.CarBean.edit(CarBean.java:51)
    How should i get this to work ????
    tx for your help,
    Roger.

    It appears that you are using ConnectionFactoryName. First be sure to
    set a ConnectionFactory2Name which will be a non-transactional (in terms
    of global transaction) DataSource for sequence generation for which you
    are seeing here. There are also some issues with JBoss's connection
    pooling on certain dbs if you are still seeing the problem after this.
    If so, try setting ConnectionURL, ConnectionPassword, etc explicitly
    Roger Laenen wrote:
    Hi all,
    I'm just trying to get the tutorial Car EJP app to work with Jboss 3.2.1
    When creating a new car record by calling the car.edit() method it reaches
    the line
    pm.makePersistent (car);
    and then throws the exception
    com.solarmetric.kodo.runtime.FatalDataStoreException:
    com.solarmetric.kodo.runtime.FatalDataStoreException:
    java.sql.SQLException: You cannot commit during a managed transaction!
    [code=0;state=null]
    When checking the jboss log, it is clear that kodo is trying to commit the
    sequence update :
    at
    org.jboss.resource.adapter.jdbc.WrappedConnection.commit(WrappedConnection.java:477)
    at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.commit(SQLExecutionManagerImpl.java:783)
    at
    com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory.updateSequence(DBSequenceFactory.java:267)
    at
    com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory.getNext(DBSequenceFactory.java:111)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.newDataStoreId(JDBCStoreManager.java:598)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.makePersistentFilter(PersistenceManagerImpl.java:1418)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.makePersistent(PersistenceManagerImpl.java:1348)
    at com.titan.kodojdotest.ejb.CarBean.edit(CarBean.java:51)
    How should i get this to work ????
    tx for your help,
    Roger.
    Steve Kim
    [email protected]
    SolarMetric Inc.
    http://www.solarmetric.com

  • TDS: Cleaning up after crash with open transactions

    I am evaluating TDS and have a pretty basic question. I have a test app that looks like this (error handling omitted).
    // main opens/creates the env, checks for 'exit' on the command line, and then calls WriteBTree
    void WriteBTree(DbEnv &env, bool exitSuddenly)
      Db table(&env,0);
      int dbResult = table.open(0, "table1.db", 0, DB_BTREE, DB_CREATE | DB_AUTO_COMMIT, 0);
      DbTxn *txn = NULL;
      env.txn_begin(NULL, &txn, 0);
      char *data = "hello world";
      for(int i=0; i<100; ++i)
        Dbt dbtKey(&key, sizeof(int));
        Dbt dbtData(data, strlen(data));
        dbResult = table.put(txn, &dbtKey, &dbtData, 0);
      if(exitSuddenly)
        cerr << "Exiting in middle of transaction" << endl ;
    exit(-1);
    dbResult = txn->commit(0);
    // cleanup here
    If I kill the app via the exit flag while a transaction is pending, the table remains locked. I can see this with db_stat. Later instances of the app hang waiting for the lock to clear. The hang occurs on the first put in the loop. Who or what will eventually remove this lock? How does my app clean up from this crash?
    I configure isalive and set_thread_id on the environment. I also configure 30 second transaction and lock timeouts. I open the env with these flags
    DB_CREATE | // If the environment does not exist, create it.
    DB_INIT_LOCK | // Initialize locking
    DB_INIT_LOG | // Initialize logging
    DB_INIT_MPOOL | // Initialize the cache
    DB_INIT_TXN | // Initialize transactions
    DB_REGISTER |
    DB_RECOVER |
    DB_THREAD |
    DB_FAILCHK;
    H^2

    I think I figured this out on my own.
    Removing the DB_FAILCHK flag from the environment flags coerced BDB into cleaning up the truncated transaction.

  • JDev 9.0.3.3 Commit issue when using Transaction DataSource

    Hi,
    Env: JDev 9.0.3.3/WL 6.0 sp1/Oracle 8i
    We have successfully deployed our application in 3-tier(remote mode) in JDev 9.0.3.2. using JClient, EO/VO, EJB Session Facade (BMT).
    Now we are planning to use JDev 9.0.3.3
    In JDev 9033 with the same code base we have issues after Commit.
    We are using ejb.txn.type=global (default) and Weblogic Transactional DataSource. It gives following error after Committing and when we navigate to some other row:
    =====================================================
    [690] BaseSQLBuilder Executing DML ... (Update)
    [691] Executing DML...
    [692] UPDATE CISDBA.DCX_X_SAVED_SEARCH SavedSearch SET DCX_MODEL_YEAR=?,DCX_USAGE_VEHICLE_FAMILY=?,DCX_END_ITEMS=?,DCX_RECORD_STATUS=? WHERE DCX_ID=?
    [693] cStmt = conn.prepareCall(" UPDATE CISDBA.DCX_X_SAVED_SEARCH SavedSearch SET DCX_MODEL_YEAR=?,DCX_USAGE_VEHICLE_FAMILY=?,DCX_END_ITEMS=?,DCX_RECORD_STATUS=? WHERE DCX_ID=?"); // JBO-JDBC-INTERACT
    [694] cStmt.setObject(1, "2004"); /*DcxModelYear*/ // JBO-JDBC-INTERACT
    [695] cStmt.setObject(2, "LX"); /*DcxUsageVehicleFamily*/ // JBO-JDBC-INTERACT
    [696] cStmt.setObject(3, "All"); /*DcxEndItems*/ // JBO-JDBC-INTERACT
    [697] cStmt.setObject(4, "All"); /*DcxRecordStatus*/ // JBO-JDBC-INTERACT
    [698] // ERROR: Unknown data type java.lang.Long // JBO-JDBC-INTERACT
    [699] cStmt.setObject(5, "206"); /*DcxId*/ // JBO-JDBC-INTERACT
    [700] cStmt.execute(); // JBO-JDBC-INTERACT
    [701] cStmt.close(); // JBO-JDBC-INTERACT
    BaseCostInvestCost VO before postChanges...
    this.getWhereClause(): null
    isDirty() before executeQuery...
    this.getWhereClause(): null
    isDirty() after executeQuery...
    BaseCostInvestCost VO before postChanges...
    this.getWhereClause(): null
    isDirty() before executeQuery...
    this.getWhereClause(): null
    isDirty() after executeQuery...
    [702] BaseSQLBuilder: releaseSavepoint 'BO_SP' ignored
    [703] BaseSQLBuilder: setSavepoint 'BO_SP' ignored
    BaseCostInvestCost VO before postChanges...
    this.getWhereClause(): null
    isDirty() before executeQuery...
    this.getWhereClause(): null
    isDirty() after executeQuery...
    BaseCostInvestCost VO before postChanges...
    this.getWhereClause(): null
    isDirty() before executeQuery...
    this.getWhereClause(): null
    isDirty() after executeQuery...
    [704] BaseSQLBuilder: releaseSavepoint 'BO_SP' ignored
    [705] EJBTxnHandler: Commited txn
    [706] BaseCostInvestCostView2 notify COMMIT ...
    [707] BaseCostInvestCostView1 notify COMMIT ...
    [708] StdCostView1 notify COMMIT ...
    [709] AltCostView1 notify COMMIT ...
    [710] PaperCarView1 notify COMMIT ...
    [711] InvestCostItemView1 notify COMMIT ...
    [712] SavedSearchView1 notify COMMIT ...
    [713] AltCostView1_BaseInvestToAltViewLink_AltCostView notify COMMIT ...
    [714] InvestCostItemView1_BaseInvestToInvestItemViewLink_InvestCostItemView notify COMMIT ...
    [715] PaperCarView_BaseCostTrackedVehicleViewLink_PaperCarView notify COMMIT ...
    [716] VehicleProgramLOV1 notify COMMIT ...
    [717] SubDeptLOV1 notify COMMIT ...
    [718] Transaction timeout set to 28800 secs
    [719] Column count: 14
    [720] ViewObject : Reusing defined prepared Statement
    [721] QueryCollection.executeQuery failed...
    [722] java.sql.SQLException: The transaction is no longer active (status = Committed). No further JDBC access is allowed within this transaction.
         void weblogic.jdbcbase.jts.Connection.checkIfRolledBack()
              Connection.java:468
         void weblogic.jdbcbase.jts.Statement.setMaxRows(int)
              Statement.java:179
         void weblogic.jdbc.rmi.internal.StatementImpl.setMaxRows(int)
              StatementImpl.java:82
         void weblogic.jdbc.rmi.SerialStatement.setMaxRows(int)
              SerialStatement.java:132
         void oracle.jbo.server.QueryCollection.executeQuery(java.lang.Object[], int)
              QueryCollection.java:534
         void
    ===================================================

    Hi Carsten,
    I tried to reproduce your problem, but couldn't. Let me explain what steps I executed and perhaps you can advise where I've not matched your steps.
    --Using build jdeveloper 9.0.3.3.1203, I built a new bc4j project containing a dept-emp default bc4j project (deptEntity, empEntity, deptView, empView, deptempFKAssoc, deptempFKViewLink, ApplicationModule).
    --In dos shell, I went to the directory \jdevdir\jdev\bin and ran setvars -go to set the correct jdk version
    --In the dos shell, in the directory \jdevdir\j2ee\home I executed the following command to install oc4j:
    java -jar oc4j.jar (defaults pswd to welcome for admin)
    --I remoted the appmodule to EJB Session Bean (BMT) and created a new deployment profile using the 9ias configuration for the application module.
    --I deployed the bc4j objects to oc4j
    --I created a new project
    --In this project I created a new jclient master-detail form using the above project's application module for the data model
    --I saved all and compiled the jclient project
    --I ran the jclient form and inserted a master record
    --I committed the transaction successfully
    --I browsed records, then edited a record
    --I committed the transaction successfully, then browsed.
    Is there something I've missed? Did you migrate your project and not start by creating a new project? Is there something special about the database schema you are using?
    Thanks,
    Amy

  • DBA commit other session's transaction?

    Hi, everyone,
    A quick question, can a DBA commit {color:#0000ff}other session's transaction{color}?
    If so, how?
    Thanks!
    Alex

    Transactions can be as long as what the user logic demands. There is no transactions that is too long or too large. Oracle doesn't break, slowdown, or underperform because of long or big transactions. If you look deep into how oracle handles transactions in the background, you'll see why.
    It's interesting you mentioned that. I hope you really looked deep into how oracle handles transactions so you can en-light us how long and large transaction not affecting performance.
    perhaps we should start with Oracle Concept shall we?
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/transact.htm#CNCPT117
    In a nutshell long and large transaction has potential performance impact at least in these aspects.
    A transaction will generate undo information, until the transaction is committed, these undo segment can't be reused. As transaction grows the undo space held hostage grows. Potential performance impact No.1
    A transaction usually hold locks on rows you made changes. until your transaction is committed, no other user can update these rows and need to wait for the lock. Potential performance impact No.2
    The third one is situation like yours, when a session held long and big transaction dropped, Oracle need to rollback all the changes made to database. Some of these changes already been flushed to disk (especially since it's long and large transaction). In that case, Oracle will need to load all changed data blocks and apply undo information back.
    On the other hand, since you are seeking ways for DBA to commit the uncommit change you made recklessly, that means you could have committed the changes. There's certainly no user logic to hold these changes as one single transaction.

  • JCA / JDBC Configured for non-XA Attempting XA Transaction Commit

    I am attempting to create simple BPEL SOA composites in SOA 11.1.1.5 that use a DbAdapter to execute a stored procedure in an 11g database. The database task being performed only involves a single database and does not require transaction support. I have carefully stepped through the creation of the DataSource and JCA pointing through the DbAdapter to the JDBC DataSource so XA transaction support is disabled, the JCA pool sets the transaction mode to "No transaction" and the JCA pool uses the dataSource value to point to the JNDI name of the JDBC pool rather than the xADataSource value.
    Visually,
    DataSource definition:
    name = jdbc/myserviceDataSource
    driver = oracle.jdbc.xa.client.OracleXADataSource
    url = jdbc:oracle:thin:@mydbhost.myfirm.com:1521:GENERIC
    use XA DataSource = unchecked
    set XA timeout = unchecked
    Keep XA connection until transaction complete = checked
    keep connection after local transaction = checked
    JCA definition:
    name = eis/DB/myserviceDataSource
    dataSourceName = jdbc/myserviceDataSource
    xADataSourceName = (blank)
    platform class name = org.eclipse.persistence.platform.database.Oracle10Platform
    Transaction | Transaction Support: no transaction
    This configuration works on one sandbox server and I got it working in a second sandbox server. However, after deleting the JDBC and JCA pools to go through the process one more time to document the procedure on the second server, I am unable to get the configuration working again. The WebLogic domain appears to be resurrecting portions of an old configuration that still references the JNDI name of the JDBC pool in the xADataSourceName parameter. I have unpacked the DbAdapter.rar archive for the DbAdapter and verified the contents of the ./META-INF/weblogic-ra.xml file don't use the xADataSouceName parameter. The Deployment Plan for the DbAdapter (named DbAdapterPlan.xml in $SOA_HOME/soa/connectors ) also explicitly configures the JCA pool using the dataSourceName value leaving the xADataSourceName value blank.
    However, executing the SOA service using this JCA connection results in this error:
    java.sql.SQLException: Cannot call Connection.commit in distributed transaction.
    Again, I know the theoretical answer to this question is to disable transactions in the JCA and JDBC configurations and don't use the xADataSourceName element of the JCA configuration to point to the JDBC pool. However, after validating those elements and restarting the pools or performing an Update on the DbAdapter deployment, WebLogic seems to still create connections through the JDBC pool with transactions enabled.
    Any suggestions?
    Should I just completely undeploy the DbAdapter and redeploy it from the SOA binary installation directory? These are just lab machines right now so that's obviously not a good long term answer for production use but may help start over with refining a better procedure for doing this.

    You should use a non-xa driver for your data source...
    From the weblogic docs...
    Configure Transaction Options
    When you configure a JDBC data source using the Administration Console, WebLogic Server automatically selects specific transaction options based on the type of JDBC driver:
    For XA drivers, the system automatically selects the Two-Phase Commit protocol for global transaction processing.
    For non-XA drivers, local transactions are supported by definition, and WebLogic Server offers the following options ...
    http://docs.oracle.com/cd/E23943_01/web.1111/e13737/jdbc_datasources.htm#autoId8
    Cheers,
    Vlad

  • Oracle post failover transaction commit error

    I have a problem on trasaction after database failover.
    Solaris 8, WLS 6.1 sp3, Oracle 8.1.7 (2 Oracle instances, one is primary and
    another is standby), JDK 1.3.1
    We found this problem in Oracle (Net 8 connection time) failover test.
    Here is what we did.
    During the load, we shut down the primary Oracle server (box).
    All in-flight transactions were wrong, this is ok.
    When new requests came in, WebLogic begin to refresh the connections.
    Because the primary Oracle server was down, it took about 70 seconds to
    refresh a connection (due to the socket timeout value) and redirect to the
    standby Oracle. This is fine.
    After a while, all connections were refreshed and all connected to the
    standby serever.
    When I opened WebLogic console to monitor the in-flight transaction, I found
    some transactions are doing committing and never finished.
    At this time most of the transaction can go through but few of them through
    an exception (attached at the end). This error could never gone although the
    frequency was not high. The strange thing is I checked the database, the
    data was committed.
    I've tried Oracle OCI driver and thin driver, both had this problem. Is
    there anyone can help me on that?
    Thanks,
    Wenji
    <Jan 28, 2003 1:49:57 PM EST> <Error> <EJB> <Exception during commit of
    transaction Name=[EJB
    com.bankframe.bp.retail.solutionset.impl.customersearch.CustomerSearchSessio
    nBean.processDataPacket(com.bankframe.bo.DataPacket)],Xid=28502:685f84a9ba5b
    1ed8(192232),Status=Committing,numRepliesOwedMe=0,numRepliesOwedOthers=0,sec
    onds since begin=122,seconds
    left=60,ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assign
    ed=prod-srv2),SCInfo[prod+prod-srv2]=(state=pre-prepared),properties=({weblo
    gic.transaction.name=[EJB
    com.bankframe.bp.retail.solutionset.impl.customersearch.CustomerSearchSessio
    nBean.processDataPacket(com.bankframe.bo.DataPacket)],
    weblogic.jdbc=t3://10.161.46.31:7101}),OwnerTransactionManager=ServerTM[Serv
    erCoordinatorDescriptor=(CoordinatorURL=prod-srv2+10.161.46.31:7101+prod+, R
    esources={})],CoordinatorURL=prod-srv2+10.161.46.31:7101+prod+):
    javax.transaction.SystemException: Timeout during commit processing
    at
    weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTra
    nsactionImpl.java:243)
    at
    weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransaction
    Impl.java:189)
    at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:272)
    at

    Wenji Tong wrote:
    Thanks, Joe!
    Things could be more complicate. I did some tests to find the details of the
    problem. Here are the results.Hi,
    This is developing into a bigger problem than I can solve informally in newsgroups,
    so I suggest that you open an official support case with this information.
    Joe
    >
    >
    1. I've done a test. In this test, I shut down the Oracle and also stop the
    load. After all threads and connection returned to the pool and all
    transactions done (roll back or abandoned), I started load again. I still
    could find this error. That means this error is not related to any in-flight
    transactions.
    2. After all connectioin failed over, this error was still not gone. The
    frequency was not high, but it was always there.
    3. In WebLogic console, monitor in-flight transaction, I saw some
    transactions were doing committing, but never finished if there was no load.
    When I saw an error printed in log, one of the committing transaction gone
    but there came out another transaction doing the commit and can't be
    finished. I'm not sure if it was related to WebLogic console's bug.
    4. Increase the transaction timeout can fix this problem. Unfortunately, we
    can't increase the transaction timeout anymore due to our business
    requirements.
    I hope those information will be helpful.
    Thanks,
    Wenji
    "Joseph Weinstein" <[email protected]> wrote in message
    news:[email protected]...
    Wenji Tong wrote:
    I have a problem on trasaction after database failover.
    Solaris 8, WLS 6.1 sp3, Oracle 8.1.7 (2 Oracle instances, one is primary
    and
    another is standby), JDK 1.3.1
    We found this problem in Oracle (Net 8 connection time) failover test.
    Here is what we did.
    During the load, we shut down the primary Oracle server (box).
    All in-flight transactions were wrong, this is ok.
    When new requests came in, WebLogic begin to refresh the connections.
    Because the primary Oracle server was down, it took about 70 seconds to
    refresh a connection (due to the socket timeout value) and redirect tothe
    standby Oracle. This is fine.
    After a while, all connections were refreshed and all connected to the
    standby serever.
    When I opened WebLogic console to monitor the in-flight transaction, Ifound
    some transactions are doing committing and never finished.
    At this time most of the transaction can go through but few of themthrough
    an exception (attached at the end). This error could never gone althoughthe
    frequency was not high. The strange thing is I checked the database, the
    data was committed.
    I've tried Oracle OCI driver and thin driver, both had this problem. Is
    there anyone can help me on that?
    Thanks,
    WenjiHi. It seems that Oracle failover is not perfect. Our transactioncoordinator
    is supposed to have control of the transaction. If a failover occurs while
    a transaction is pending, the coordinator should still have the ability toroll
    back the tx. Apparently there are cases where the failover causes an open
    transaction to be committed, in such a way that even if the coordinatorhas
    decided to roll it back, it can't. These may be when the failover occurswhile
    we are waiting for the commit call to return. We either get an exceptionor
    we get no return from the commit() call so we try to roll back and fail.The
    actual commit succeeded, but we never knew.
    Joe
    <Jan 28, 2003 1:49:57 PM EST> <Error> <EJB> <Exception during commit of
    transaction Name=[EJB
    com.bankframe.bp.retail.solutionset.impl.customersearch.CustomerSearchSessio
    >nBean.processDataPacket(com.bankframe.bo.DataPacket)],Xid=28502:685f84a9ba5b
    >1ed8(192232),Status=Committing,numRepliesOwedMe=0,numRepliesOwedOthers=0,sec
    onds since begin=122,seconds
    left=60,ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assign
    >ed=prod-srv2),SCInfo[prod+prod-srv2]=(state=pre-prepared),properties=({weblo
    gic.transaction.name=[EJB
    com.bankframe.bp.retail.solutionset.impl.customersearch.CustomerSearchSessio
    nBean.processDataPacket(com.bankframe.bo.DataPacket)],
    weblogic.jdbc=t3://10.161.46.31:7101}),OwnerTransactionManager=ServerTM[Serv
    >erCoordinatorDescriptor=(CoordinatorURL=prod-srv2+10.161.46.31:7101+prod+, R
    esources={})],CoordinatorURL=prod-srv2+10.161.46.31:7101+prod+):
    javax.transaction.SystemException: Timeout during commit processing
    at
    weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTra
    nsactionImpl.java:243)
    at
    weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransaction
    Impl.java:189)
    atweblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:272)
    at

  • Removing the entity object commit from transaction handler

    Hi,
    The business reuirement of the OAFWK page developed by us is as explained below:
    The basic functionality is of updating the attributes of items attached to the change order.
    The UI components displayed in the page(Item attribute changes region) are built based on the properties of the item attributes as LOV,poplist,textbox etc..
    The dynamic VO mapped to these UI components is based on a standard entity object.
    User operation:Select any attribute group and click on Go button.The Item attributes of the attribute group are displayed.Enter values in the Item Attributes and click on Apply button of the region.(changes made in the attributes related to the attribute group are committed to the database using
    &lt;Root AM&gt;.getTransaction.commit()).
    Now we have two such regions in the same page.
    On top of the page the item attributes of _{color:#800000}&lt;Item Type X&gt;{color}_ are displayed.
    Down the page, the item attributes of {color:#0000ff}&lt;_Item Type Y_&gt;{color} are displayed.
    In few special cases i.e for few item attributes, on click of Apply button for {color:#0000ff}_Item Y_{color} , the attributes of {color:#800000}I_tem X_{color} are to be updated by calling a PLSQL API.When Apply button in the Item attributes of _{color:#0000ff}Item Type Y{color}_ is clicked,the execution of controllers is :
    1.Controllers of Item attribute changes region of {color:#800000}&lt;Item Type X&gt; {color}The dynamic VO is built for the item attributes of Item Type X
    2.Controllers of the Item attribute changes region of {color:#0000ff}Item Type Y{color} The dynamic VO is built for the item attributes of Item Type Y.In the last controller of the hierarchy, the PLSQL API call is included(by invoking the method in AM) to update few attribute values of {color:#800000}Item Type X and finally &lt;Root AM&gt;.getTransaction().commit().
    Problem : The updated values by PLSQL API for {color:#800000}_Item Type X_{color} are not reflected in the database but indeed the values entered by user for {color:#800000}_Item Type X_{color} in the top of the page are committed(The Apply button for {color:#800000}_Item Type X_{color} is not clicked).
    _&gt;&gt;Please note that the dynamic VOs of both the Item Types are built on the same standard Entity Object_
    I am struggling to know the reason why the values updated by PLSQL API are overwrittem by the values in the entity object even though the PLSQL API is called in the last controller of execution.Please let me know if there is any OAFWK constraint.
    I tried the approach of removing the commit of the dynamic VO built in the region of {color:#800000}_Item Type X&gt;_ {color}{color:#000000}I fetched the entity implementation of the dynamic VO row and used removeandRetain(),revert().But this approach failed.I am referring to the jdevdoc for the built-in methods.
    {color}
    Now the requirement is the latest values updated by API (for {color:#800000}_Item Type X_{color}) should be committed in the database but not the values updated by the entity object for {color:#800000}_Item Type X_ {color}{color:#000000}in the item attributes region{color}.
    There should a single commit for the entire transaction of the page.
    Is there any chance to remove the commit of item attributes of {color:#800000}_Item X_{color} alone from the transaction handler?There are few methods in oracle.jbo.server.EntityImpl class such as doRemoveFromTransactionManager().But these methods are either protected or private.So classes of other packages cannot access them.
    So pelase suggest me if there is a workaround for this scenario.
    Thanks and Regards,
    Kiran
    Edited by: Kiran.A on Sep 20, 2008 3:34 AM

    Hi Sumit,
    Yes I agree on that front that updating the same record through PLSQL and EO is not the right approach.
    But the business requirement is as such and we do not have any workaround for this.
    Please let me know if there is any way to avoid the EO commit by removing from transaction listener.
    Regards,
    Kiran

  • How to permit a transaction commit in applet?

    my code like this:
    Registry.set("secure.allowSaveFileFromApplets", JMFI18N.getResource("jmfregistry.settings.allowfilewrite") );
    Registry.set("secure.allowCaptureFromApplets", JMFI18N.getResource("jmfregistry.settings.allowcapture") );
    try {
    Registry.commit();
    catch (IOException ioe) {
    System.err.println("Error:"+ioe);
    I have signed the applet,but when execute,Exception as follows,
    java.lang.SecurityException: commit: Permission denied
         at com.Registry.commit(Registry.java:274)
         at com..JMFRegistry.doCommit(JMFRegistry.java:22)
    the line:Registry.commit(),sames use a transaction commit,but java.policy file no the permission,so,how to add the permission to the file?
    dying for help!!!
    s.

    I face with the same problem. i can do it in standalone java application but i cannot do the same thing in web start. i get the same "commit: Permission denied" exception. i got really stuck with the problem. i will greatly appreciate if you post the solution if you can find or found any.
    i will post any solution if i can find any.

  • Cannot commit during managed transaction

    Using Kodo 2.5.2, JBoss 3.2.1, and the DefaultDS datasource (HSQL)
    provided by JBoss, I'm getting the following exception when calling
    PersistenceManager.makePersistent:
    java.sql.SQLException: You cannot commit during a managed transaction!
    at
    com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.throwFatal(SQLEx
    ceptions.java:58)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.handle(SQLExcept
    ions.java:43)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.newDataStoreI
    d(JDBCStoreManager.java:562)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.makePersistentFil
    ter(PersistenceManagerImpl.java:1450)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.makePersistent(Pe
    rsistenceManagerImpl.java:1380)
    Any idea why?
    -Chris

    Using Kodo's connection pooling fixed the problem.
    Thanks for the help.
    Chris West wrote:
    I suspect JBoss connection pooling could be the problem. A couple of
    questions...
    1. Do you know which versions of JBoss have this problem.
    2. How do I configure Kodo to use it's own connection pool on JBoss?
    -Chris West
    Stephen Kim wrote:
    I would highly suggest using Kodo's connection pool first and see if
    that alleviates the problem. I recall JBoss having some connection pool
    issues in certain versions.
    Steve Kim
    [email protected]
    SolarMetric Inc.
    http://www.solarmetric.com

  • Javax.transaction.SystemException: Timeout during commit processing

              In my Workshop 8.1 SP2 project I have a Custom Java Control whose methods I call
              from my JPF. From that custom control I create a remote connection to a Weblogic
              6.1 Application server. I execute remote methods and get the expected objects
              back with no problem. The problem is that I cannot return that object from my
              custom control back to my jpf. As soon as the method's return statement is executed,
              the process hangs for a considerable period of time and then throws the following
              Exception:
              An error has occurred:
              Exception while commiting Tx : Name=[EJB com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)],Xid=BEA1-0005BF0F3E6E72419698(655489),Status=Unknown,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
              since begin=217,seconds left=42983,XAServerResourceInfo[BMResourceManager]=(ServerResourceInfo[BMResourceManager]=(state=new,assigned=none),xar=null),SCInfo[midway+cgServer]=(state=active),SCInfo[prdsdomain+prdsserver]=(state=active),properties=({weblogic.transaction.name=[EJB
              com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=cgServer+172.23.83.174:7001+midway+t3+,
              XAResources={},NonXAResources={})],CoordinatorURL=prdsserver+172.23.4.109:7041+prdsdomain+t3+);
              nested exception is:
              javax.transaction.SystemException: Timeout during commit processing
              Start server side stack trace:
              javax.transaction.SystemException: Timeout during commit processing
              at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:243)
              at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:189)
              at weblogic.transaction.internal.CoordinatorImpl.commit(CoordinatorImpl.java:68)
              at weblogic.transaction.internal.CoordinatorImpl_WLSkel.invoke(Unknown Source)
              at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
              at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274)
              at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:22)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              End server side stack trace
              caused by: : javax.transaction.SystemException: Timeout during commit processing
              Start server side stack trace:
              javax.transaction.SystemException: Timeout during commit processing
              at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:243)
              at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:189)
              at weblogic.transaction.internal.CoordinatorImpl.commit(CoordinatorImpl.java:68)
              at weblogic.transaction.internal.CoordinatorImpl_WLSkel.invoke(Unknown Source)
              at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
              at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274)
              at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:22)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              End server side stack trace
              As soon as I take out RMI calls from my custom control's code, I can return any
              object I want back to my JPF. Here is the what I am thinking is happenning.
              The system that runs on Weblogic 6.1 manages its own transactions and begins a
              new transaction every time a session bean residing on that server is invoked.
              In addition, Weblogic 8.1 starts an internal transaction when the Custom Java
              Control makes a call. Could there be some kind conflict? If yes, is it possible
              to disable transactions from the Java Control?
              Thank you very much
              Alex Mayzlin
              

    Horst,
              "aa aa" <[email protected]> wrote in message news:20701457.1093414960276.JavaMail.root@jserv5...
              > we are getting the same Exception. As nobody replied to your question, it would be interesting, if you found any solution
              yourself?
              >
              > Additional info:
              > We are also getting these error messages from BEA when testing connections in pool before and after the exception:
              >
              > <20.08.2004 19.32 Uhr CEST> <Error> <JDBC> <BEA-001112> <Test "SELECT count(*) FROM invoice" set up for pool "ABCConnection Pool"
              failed with exception: "java.sql.SQLException: ORA-01591: lock held by in-doubt distributed transaction 4.47.141655".>
              Generally it's a good idea to use Oracle's system DUAL table
              for testing connections on reserve. Try to change your ABCConnection
              connection pool configuration to use DUAL as the test table
              instead of "invoice".
              Regards,
              Slava Imeshev
              

  • What happens if there is an error during a commit?

    What happens if an error occurs while committing a transactional resource?
              For example, say the transaction manager successfully sends a commit
              notification to two transactional resources at the end of a transaction, but
              then gets an error while trying to commit a third one. It can't rollback the
              first two because they've already been committed. Is it up to the client to
              perform forensics in this case, or is it too rare to account for?
              Bob
              

    Bob,
              This is exactly the problem that is solved by "2 phase commit" of transactions.
              The JTA transaction manager will not tell the 3 resources to commit. Instead,
              it will tell them all to "prepare" - it is the resources' responsibility to
              confirm that they have prepared only when they have written the post transaction
              stast to disk and KNOW that they can commit, if required, in the future.
              When all 3 prepares have returned OK, the transaction manager writes a record to
              disk confirming its decision to commit. Only then will it go ahead and tell the
              resources to commit.
              Hence, in your secnario, the 3rd prepare will fail and the transaction manager
              will tell the other 2 resources to roll back.
              Of course, if something catastrophic happened (disk head crash, fire...) then a
              commit may fail, leaving the results inconsistent as in your scenario. This is
              termed a "Heuristic completion" and you need to send in the DBAs to take care of
              the forenzics that you are worried about.
              For a more detailled discussion of this, take a look at
              http://dev2dev.bea.com/articlesnews/discussion/thread.jsp?forum=1&thread=106
              I hope that helps,
              Peter.
              Got a Question? Ask BEA at http://askbea.bea.com
              The views expressed in this posting are solely those of the author, and BEA
              Systems, Inc. does not endorse any of these views.
              BEA Systems, Inc. is not responsible for the accuracy or completeness of the
              information provided
              and assumes no duty to correct, expand upon, delete or update any of the
              information contained in this posting.
              Bob Lee wrote:
              > What happens if an error occurs while committing a transactional resource?
              >
              > For example, say the transaction manager successfully sends a commit
              > notification to two transactional resources at the end of a transaction, but
              > then gets an error while trying to commit a third one. It can't rollback the
              > first two because they've already been committed. Is it up to the client to
              > perform forensics in this case, or is it too rare to account for?
              >
              > Bob
              >
              >
              >
              

  • SBS2011 - odd behaviour - IIS / WAS crashed

    Hi,
    This night, on a customer's SBS2011 server, WAS reported an event 5080, where was mentioned that the SBS SharePoint appPool will be recycled due to 1 or more config changes. The config file involved was corrupted (eventID 5189)
    After that i see a waring (I don't know if it is related) of Kernel-Tm, eventID 1:
    The Transaction (UOW={bfbaf6f6-30c3-11e3-9bd7-001e67861381}, Description='') was unable to be committed, and instead rolled back; this was due to an error message returned by CLFS while attempting to write a Prepare or Commit record for the Transaction. 
    The CLFS error returned was: 0xc01a002f.
    Then things went fast:
    WAS 5189:
    The Windows Process Activation Service failed to generate an application pool config file for application pool '*'. The error type is '0'. To resolve this issue, please ensure that the applicationhost.config file is correct and recommit the last configuration
    changes made. The data field contains the error number.
    and a few others that mention cannot initialize and start (5036 and 5005)
    After that IIS crashes and could not be started again. Even after restoring the SharePoint App Pool's original config file from the backup
    Now I read in several forums that in this cases IIS needs to be reinstalled. But his is an SBS2011, which is pretty much preconfigured by windows itself. Is there a good procedure of what I should do?
    Or are there other better ways that I did not see?
    And of coarse: I didn't see this happen on SBS2011 servers before.... what is this??? A possible hack?
    Greetings,
    Alexander

    Later, after business hours I could do a reboot.
    Fortunately, that resolved the problems :-)
    Still I hope that someone knows a way to solve such issues without having tot reboot the SBS ...

  • 2.3.8 Container::getAllDocuments() appears to close the transaction

    When I execute the following I get a error saying that the transaction has already been committed or aborted.
    void MyFunc(XmlTransaction& txn,XmlResults result)
       while(retry){
          try{
             result = myContainer->getAllDocuments(txn,DB_READ_COMMITTED);
             return;
          catch(){...catch handler...}
    void SomeOtherFunc(...)
       //init....
       XmlTransaction txn = xmlManager->createTransaction();
       XmlResults res;
       MyFunc(txn,res);
       txn.commit(); // crashes here!!!
       // Do something with the results
    }

    What's going on inside your catch handler in MyFunc()? If you are catching deadlocks and retrying, that'd be the problem. Are you seeing this fail every time, and even when there are no retries?
    Regards,
    George

Maybe you are looking for