Bean Managed Transactions

Dumb question?
Is there a way to change one of the methods in a container-managed bean so that it is bean-managed?

More specifically, I'm confused by the format for ejb-jar.xml.
If I use the following to specify whether a bean is managed by the container or by the bean itself...
    <enterprise-beans>
        <session>
            <description>This is an example bean.</description>
            <display-name>MyExample</display-name>
            <ejb-name>MyExample</ejb-name>
            <home>cc.ejb.SessionBeanHome</home>
            <remote>cc.ejb.SessionBeanRemote</remote>
            <ejb-class>cc.ejb.MyExampleBean</ejb-class>
            <session-type>Stateless</session-type>
            <transaction-type>Bean</transaction-type>
        </session>
    </enterprise-beans>... then what is the purpose of this section:
    <assembly-descriptor>
         <container-transaction>
                <method>
                       <ejb-name>MyExample</ejb-name>
                       <method-name>*</method-name>
                </method>
                <trans-attribute>Required</trans-attribute>
         </container-transaction>
    </assembly-descriptor>Any help or direction is appreciated.

Similar Messages

Bean-managed transaction with EJB 3.0

Hi,
I try to get a bean-managed transaction example running with EJB 3.0 under GlassFish v2ur2.
In order to demarcate the scenario I have to get me the UserTransaction which I get from the SessionContext. I would like to use it then like: UserTransaction ut = context.getUserTransaction();
I tried to get the SessionContext with the help of the EJB method setSessionContext which should be called by the container after instance creation.
However, setting a log output into that method does not show any call of this method.
So, how can I get this method called or is there another way to get the SessionContext for the UserTransaction to work ?
Are there any good and fully implemented examples for bean-managed transactions ?
Thanks for your help.
Regards

I found the solution for that my SessionContext was NULL and I could not use the UserTransaction.
The reason for it is that I injected the EJB with @EJB into my servlet and did a MyBean mybean = new MyBean();
That leads to a SessionContext which is NULL within my EJB.
If I use it without instantiating it it works fine.
Again, thanks for your help. At least it pointed me into the right direction.
Regards

Two phase commit and bean managed transactions

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


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

Container-managed / bean-managed transaction demarcation

I am trying to make sure I understand container-managed and bean-managed transaction demarcation and in particular where you have one bean calling another bean. What happens where one of the beans has container-managed transaction demarcation and the other bean-managed transaction demarcation. In fact the initial question to ask is, is this allowed?
Lets use an application scenario to illustrate the issue. The application has a payment transaction. Payments can be received in one of two ways:
1. As a payment at a branch where the individual payment is processed on a client application and resulting in the processing of a single payment transaction.
2. As a batch of payments received from a bank containing, potentially, thousands of payment transactions.
The proposed implementation for this uses two session beans. The first is a Payment session bean that implements the business logic as appropriate calling entity beans to persist the change. The second is a BatchPayment session bean. This processes the batch of payment transactions received from the bank. The BatchPayment reads through the batch of payments from a bank calling the Payment session bean for each payment transaction.
Lets look at the transactional properties of both session beans. In order to support the client application the Payment session bean can implicitly enforce transactional integrity and is therefore set to container-managed transaction demarcation. However the BatchPayment session bean will want to explicitly specify transaction demarcation for performance reasons. The transactional "commit" process is relatively expensive. When processing a large batch of transactions rather than performing a commit after every transaction is processed we want to perform the commit after a number of transactions have been processed. For example, we may decide that after every 100 transactions have been processed we commit. The processing will have a shorter elapsed time as we have not had to perform 99 commit processes. So the BatchPayment session bean will want to explicitly specify its transaction demarcation and will therefore be defined with bean-managed transaction demarcation.
How would this be implemented? A possible solution is:
Payment session bean implemented with container-managed transaction demarcation with transaction scope set to Required.
BatchPayment session bean implemented with bean-managed transaction demarcation with transaction scope set to Required.
When the client application is run it calls the Payment bean and the container-managed transaction demarcation ensures the transactional integrity of that transaction.
When a BatchPayment process is run it explicitly determines the transaction demarcation. Lets say that after every 100 Payment transactions (through 100 calls to the Payment session bean) have been processed the BatchPayment bean issues a commit. In this scenario however we have mixed container-managed and bean-managed transaction demarcation. Hence my original question. Can container-managed and bean-managed transaction demarcation be mixed? If not how is it possible to implement the requirements as described above?
Thanks for any thoughts.
Paul

BatchPayment session bean implemented with bean-managed transaction demarcation with transaction scope set to Required.Didn't quite understand this sentence.... if it's BMT it has no declarative transaction attributes such as "Required"....
Anyway, first of all I'll have to ask, Why at all would you want to commit in the middle of the business method? to get as much through as possible before a potential crash? :-)
Can container-managed and bean-managed transaction demarcation be mixed?Yes, of course. Just remember that the "direction" you are refering to ->
a BMT SB that propagates it's transaction to a method in a CMT SB that is demarcated with "Required" is the simplest case. If it were "reversed", or for that matter any BMT that might be called within an active transaction context must perform logic to manipulate the transaction state. For instance(and most common case), checking to see if a transaction is active and if so not to do anything(just use the one that is already active).
If not how is it possible to implement the requirements as described above?You could also implement this scenario with CMTs all the way through. your BatchPayment SB could consist of two methods, one (say, execute(Collection paymentsToExecute) ) with "Supports", and another(say executeBatchUnit(Collection paymentsToExecute, int beginIndex, int endIndex) ) with "RequiresNew".
then have the first just call the other with indexes denoting each time a group of payments.
Still, it does seem more suitable using BMT for these kind of things.....
Hope this helped....

About Container-managed Transactions and Bean-managed Transactions

as the document of weblogic7.0 describe the differents of Container-managed
          Transactions and Bean-managed Transactions,and in the document,It tell us
          details of using Bean-managed Transactions,such as \:
          import javax.naming.*;import javax.transaction.UserTransaction;.....
          import java.sql.*;import java.util.*;
          UserTransaction tx = (UserTransaction)
          ctx.lookup("javax.transaction.UserTransaction");tx.begin();
          tx.commit() //or tx.rollback
          but how to use Container-managed Transactions?
          what is EJB's deployment descriptor? can someone tell me?
          i wonder someone will show me an example of how to use Container-managed
          Transactions.
          thanks
          fish


Many if not all of the WLS EJB examples use container-managed
          transactions. That's a good place to start.
          I'd also recommend that you pick up a decent EJB book. There's several
          on the market right now.
          -- Rob
          fish wrote:
          > <ejb-jar>
          > <enterprise-beans>
          > <session>
          > <ejb-name>testbean</ejb-name>
          > <home>test.test.TestHome</home>
          > <remote>test.test.Test</remote>
          > <ejb-class>test.test.TestBean</ejb-class>
          > <session-type>Stateful</session-type>
          > <transaction-type>Container</transaction-type>
          > </session>
          > </enterprise-beans>
          >
          > <assembly-descriptor>
          > <container-transaction>
          > <method>
          > <ejb-name>EmployeeRecord</ejb-name>
          > <method-name>*</method-name>
          > </method>
          > <trans-attribute>Required</trans-attribute>
          > </container-transaction>
          > </assembly-descriptor>
          > </ejb-jar>
          > ----------------------------------------------
          > seems i have to write ejb-jar.xml like this,am i right?
          > what about <ejb-client-jar>? is it needed in this xml file?
          >
          > thanks
          >
          > fish
          >
          >

Bean-Managed Transaction and xDoclet

Hi,
i am new by xDoclet.
Does anybody know, how to specify Bean-Managed Transaction by EJB using xDoclet.
Thank you very much for any hint or link.
--Eugen

Thanks Dhiraj for helping,
I have a application module called TestAppModule. TestAppModule should be deployed as Bean Managed Service Bean. In the Remote of the Application Module, I chose BmtServiceBean. 3 files were created
RemoteTestAppModule.java
TestAppModuleHome.java
TestAppModuleServer.java
In ejb-jar.xml, this tag was added
<enterprise-beans>
<session>
<description>Session Bean ( Stateful )</description>
<display-name>TestAppModule</display-name>
<ejb-name>testBc4jComponents.TestAppModule_bmservice</ejb-name>
<home>testBc4jComponents.common.serviceejb.beanmanaged.TestAppModuleHome</home>
<remote>testBc4jComponents.common.serviceejb.beanmanaged.RemoteTestAppModule</remote>
<ejb-class>testBc4jComponents.server.serviceejb.beanmanaged.TestAppModuleServer</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Bean</transaction-type>
</session>
</enterprise-beans>
In Orion-ejb-jar.xml
<session-deployment name="testBc4jComponents.TestAppModule_bmservice"/>
I deployed the bean into oc4j.
In the Bean Where I am managing the Transaction.
Context ctx = new InitialContext();
Object home = ctx.lookup("testBc4jComponents.TestAppModule_bmservice");
TestAppModuleHome testAppHome = (TestAppModuleHome) PortableRemoteObject.narrow(home, TestAppModuleHome.class);
When I am looking up the Appmodule Bean, I reached an error stating "Serialization Error, The TestAppModuleImpl is not Serializable"
Please let me know what I am doing wrong?
Thanks
Senthil

Bean Managed Transactions and rollback

Hi Everybody,
I am using Bean Managed Transactions in a Message Bean which is called every some time by an EJB3 timer. This Message Bean subsequently calls a Session Bean which uses Container Managed Transactions and uses the default transaction attribute which is SUPPORTS. The Session Bean methods might sometime throw a System Exception(inheriting from RuntimeException) which will rollback the Bean Managed Transaction which was started from the Message Bean.
When this happens and I try to invoke userTransaction.rollback() I get invalid transaction state exception and I suppose this means that is already rolled back.
Is there a way to get another transaction or set the transaction back to a valid state so I can carry on with some persistence tasks or the only way to do that is by suppressing the RuntimeException and throwing an Application Exception having the *@ApplicationException(rollback=false)* annotation? Can I suppress a System Exception though?
Thank you in advance!

Saroj wrote:
Hi All,
I would like to know whether we can use JDBC Connection Object's commit and rollback
methods to control Transaction in Bean Managed Transactions or not.You may use the JDBC connection's transaction support from an EJB. That being said, you
need to understand that it won't be the transaction that started declaratively by the
EJB container nor would it be a bean-managed transaction started through
UserTransaction.
FWIW, I question why you'd want to do this though. I'd use container-managed
transactions and let the container handle this for you. The transaction manager
includes a 1PC optimization so it's not going to do an XA/2PC tx if you only have a
single resource in the tx. Also, the EJB container includes all the logic to properly
handle rollbacks when exceptions are thrown etc.
Finally, your code will more maintainable and reusable if you use the container-managed
tx + JTA resources. If I later wanted to call another EJB or another JTA resource (eg
JMS perhaps) I could do it without having to rewrite all of your code.
-- Rob
>
>
Why is it required that we should use Java Transaction API to control the Transaction
in Our Beans?
I understand that if we are using Multiple Resources and need to use Transaction
then going for JTA makes sense. If I am using only Resource,for example, Only One
Connection then we should be able to use Connection's Transaction control.
I understand that other way to do the transaction is to use Container's transaction
services.
Please respond at the earliest.
Thanks in Advance,
Saroj

Can i call Bean managed EJB with transaction attribute Required New

          I am calling a BeanManaged EJB which has a transaction attribute
          set to Required New from a container managed bean. Does it create a new transaction
          other than the Bean managed transaction. Do i really need a required new field
          transaction attribute.All i need is user controlled transaction.Do i need to set
          the transaction aatibute.
          Thanks
          Krish.


Hi Krish,
          The question does not make much sense.
          I would suggest that you set all your tx settings to "Required" unless you
          have a specific reason to do otherwise, and in those few instances that you
          have a specific reason to do otherwise, then change it in just those places.
          Peace,
          Cameron Purdy
          Tangosol Inc.
          << Tangosol Server: How Weblogic applications are customized >>
          << Download now from http://www.tangosol.com/download.jsp >>
          "KRISH" <[email protected]> wrote in message
          news:[email protected]..
          >
          > I am calling a BeanManaged EJB which has a transaction attribute
          > set to Required New from a container managed bean. Does it create a new
          transaction
          > other than the Bean managed transaction. Do i really need a required new
          field
          > transaction attribute.All i need is user controlled transaction.Do i need
          to set
          > the transaction aatibute.
          >
          > Thanks
          >
          > Krish.
          >

Container managed transactions in 9.0.3 (plus AQ JMS/MDB)

Something for "real programmers", similar to MDB Transaction Exception on OC4J 9.0.4 (MDB Transaction Exception on OC4J 9.0.4) but little bit different. Maybe author of the mentioned thread can find some answers here also.
We have an MDB accessing AQ in database (this works either with 9i and 8i). MDB receives the message (actually TextMessage), retrieves the content/properties and calls some EJBs making database operations. When we used just the same DataSource for JMS resource provider and SQL operations, everything worked OK. But we need to move one step further - making calls to several databases, some 8i, some might 9i. We were able to start CMT for one DataSource, i. e. configuring OrionCMTDataSource over JDBC ORACLE driver (if you use different DataSource class, message remains stucked in queue and eventually expires. If you don't specify container managed transactions for MDB in ejb-jar.xml, it works with any DataSource class - but message is lost every time exception occurs - not very pleasant situation).
We are trying to configure DataSources so they provide transactional support while using commit coordinator. There are some documents describing this - in 9iAS Data Sources and JTA, Orion Data Sources and possibly JTA description in 9i database documentation. Both ORACLE documents are very similar. Generally, these are main steps:
1) configure each data source so they provides CMT support (wrap native driver/data source by OrionCMTDataSource class)
2) create datasource commit-coordinator database, also using CMT(?)
3) create user in commit-coordinator database and same in each other database with connect, resource, create session + force any transaction priviledge (since it would commit other users transactions)
4) create database links from commit-coordinator database to each databases (but... see questions below)
5) configure commit coordinator so it uses proper data source
6) add each DB link as a property to data sources
7) configure data source for JMS
8) connect JMS resource provider with JMS data source
9) Start container, send message, etc.
So far the only result we've got is a trace file in database user dumps and generic "javax.transaction.SystemExeption: Could not commit: error code 29540". User dump occurs in a "remote" database, not the one where commit coordinator resides. If I drop database links, result is the same, so it seems like problem with data source itself. In a dump there is piece of text like this: "FATAL ERROR IN TWO-TASK SERVER: error = 12571" and "ksedmp: internal or fatal error
Current SQL statement for this session:
begin dbms_aqin.aq$_dequeue_in( :1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19, :20, :21, :22, :23, :24, :25, :26, :27, :28, :29); end; ". I think AQ call is just a coincidence since it is the first one involved in transactions. Down there in HEX part of a dump there is a message about protocol or network error ("probably ORA-28546")
Here is an example of data source configuration we are using:

<data-source
name="PassportDS"
class="com.evermind.sql.OrionCMTDataSource"
location="jdbc/PassportDS"
connection-driver="oracle.jdbc.driver.OracleDriver"
username="int"
password="int"
url="jdbc:oracle:thin:@ws18885:1521:ICON"
inactivity-timeout="30">
<property name="dblink" value="ICON.WS18885.APPG.COM"/>
There are some questions pending. Obvious one is if CMT is working or not at all and we should find some different solution (Bean managed transactions or use XA, hmmm). Other one might be that database link has to be "fully-qualified". I'm not sure what it means: using username and password? Using database name along with domain (if any)? So far it seems links are not used anyway.
We've tried several databases, like 9.2.0.1 and 9.0.3 versions. Result is the same.
We've tried to use XA data source of ORACLE (oracle.jdbc.xa.client.OracleXADataSource) and OrionCMT data source bound by xa-source-location to it but container gets stucked upon restart with "Investingating resource 'XADataSource PassportXADS' for recovery..." and similar messages for an hour.
There is an OracleJTADataSource mentioned in several documents, but I cannot find any in jdbc classes - was it deprecated?
Lies the problem in JMS itself? So far we've been able to use AQ in 8i and 9i and succesfully commit every transaction - provided transaction was local.
Since XA itself is working I guess problem might be with configuration.
I will appreciate any opinion on CMT... also, if you have any questions, please ask.
Myrra

Hi Per,
I don't have an answer for you -- sorry {:-( -- only a suggestion (which
you may have already tried, anyway :-). Have you tried running OC4J
in "debug" mode? The following web-page gives details on how to do that:
http://kb.atlassian.com/content/atlassian/howto/orionproperties.jsp
Also, if you aren't already aware of them, the following web-sites
may also be helpful (not in any particular order):
http://www.orionserver.com
http://www.orionsupport.com
http://www.elephantwalker.com
Good Luck,
Avi.

Bean-managed persistence?

Hi,
Can someone explain to me if there is a diffetent between bean managed persistence and bean managed transaction?
Or where I can read about it?
Thanks,
Julia

sun has several articles about both of these concepts. You can probably find them via an Internet search. Here is one of the documents:
http://java.sun.com/j2ee/tutorial/1_3-fcs/index.html

Entity Bean can only use container-managed transaction demarcation?

In <<Designing Enterprise Application with J2EE 2nd>>
Section 2.3.3.3 Enterprise Bean Transactions,it says:Entity beans can only use container-managed transaction demarcation.
That means,i can not get UserTransaction from EJBContext.
Is that true?

Yes this is the requirement of the specs. Your ejb code generator should give you the error if you use usertransaction.
--Ashwani

Can i user UserTransaction in a Container-managed transaction Bean

can i use UserTransaction to control transaction boundaries in a container-managed transaction bean method?
below is the method:
there is one-to-many between Employees and SalaryItem
@TransactionAttribute(value = TransactionAttributeType.REQUIRED)
private void initEmployeesSalary(Long salarySumId) {
for(Employees employees: liEmployees){
for (int i = 0; i < 20; i++) {
SalaryItem item = new SalaryDetailItem();
employees.addSalaryItem(item);
when there are about 1000 employees,the method run very slow.
What do you think I should do?
null

Hi again,
The EJB specs say that a stateful Session Bean with CMT is NOT allowed to use the UserTransaction; see page 361 of the EJB2.0 specification. So combining them will not (or should not) work.
I suggest CMT+SessionSynchronization combined with using a flag to indicate whether notify should be called or not. Otherwise, you could try splitting up the bean into two beans: one with CMT and another one without. The one without CMT could use the UserTransaction and notify.
Also, you might want to check http://www.onjava.com/pub/a/onjava/2001/10/02/ejb.html
Hope that helps a bit,
Guy
http://www.atomikos.com

Does WLS 6.1 sp2 allow (bean managed) entity beans to have transaction mode NOTSUPPORTED?

Hi,
I have created two bean managed entity beans, User and Role, abstracting users
and groups in a ldap base. A User may have more than one Role. This is represented
by a (bean managed) 1:many relationship directed from User to Role. For some weird
reasons I get a transaction rollback when reading data, when transactions are
turned on (REQUIRED).
While we where running WLS 6.1 sp1 we had no problems with this as we could set
transaction to NOTSUPPORTED for these two EJBs. Due to other hickups we had to
upgrade to sp2 and suddenly the error reappears leading me to believe that NOTSUPPORTED
isn't allowed anymore by the WLS. I know that NOTSUPPORTED isn't required by the
EJB spec, but containers may support it and obviously WLS used to do just that.
I have not seen any change in the release notes of sp2 that indicates that this
behaviour has changed.
Does anybody know if WLS really doesn't support NOTSUPPORTED for enity beans anymore
in sp2?
If anybody are curiuos or have any good ideas, the stacktrace I get is:
javax.ejb.TransactionRolledbackLocalException: EJB Exception:
- with nested exception:
[javax.ejb.EJBException
- with nested exception:
[weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion:
sync=weblogic.ejb20.internal.TxManager$TxListener@1c2906 - with nested exception:
[java.util.ConcurrentModificationException]]]
Start server side stack trace:
java.rmi.RemoteException: EJB Exception: ; nested exception is:
     javax.ejb.TransactionRolledbackLocalException: EJB Exception:
- with nested exception:
[javax.ejb.EJBException
- with nested exception:
[weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion:
sync=weblogic.ejb20.internal.TxManager$TxListener@1c2906 - with nested exception:
[java.util.ConcurrentModificationException]]]
java.util.ConcurrentModificationException
     at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:535)
     at java.util.LinkedList$ListItr.next(LinkedList.java:476)
     at weblogic.ejb20.manager.DBManager.beforeCompletion(DBManager.java:370)
     at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManager.java:481)
     at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:551)
     at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:88)
     at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:980)
     at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1504)
     at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:216)
     at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:190)
     at weblogic.ejb20.internal.BaseEJBLocalObject.postInvoke(BaseEJBLocalObject.java:207)
     at com.takecargo.domainentities.role.RoleBean_1ipw6_ELOImpl.getName(RoleBean_1ipw6_ELOImpl.java:86)
     at com.takecargo.domainentities.role.RoleConverter.getVOforRoleLocal(RoleConverter.java:51)
Any kind of help would be appreciated:)
Regards,
Brynjar Glesnes

WLS support NotSupported on Entity Beans.
It looks like you've hit a bug in the EJB container where an internal Collection class has been modified while the
container is running through an iterator on it.
You should open a case with [email protected]
-- Rob
Brynjar Glesnes wrote:
Hi,
I have created two bean managed entity beans, User and Role, abstracting users
and groups in a ldap base. A User may have more than one Role. This is represented
by a (bean managed) 1:many relationship directed from User to Role. For some weird
reasons I get a transaction rollback when reading data, when transactions are
turned on (REQUIRED).
While we where running WLS 6.1 sp1 we had no problems with this as we could set
transaction to NOTSUPPORTED for these two EJBs. Due to other hickups we had to
upgrade to sp2 and suddenly the error reappears leading me to believe that NOTSUPPORTED
isn't allowed anymore by the WLS. I know that NOTSUPPORTED isn't required by the
EJB spec, but containers may support it and obviously WLS used to do just that.
I have not seen any change in the release notes of sp2 that indicates that this
behaviour has changed.
Does anybody know if WLS really doesn't support NOTSUPPORTED for enity beans anymore
in sp2?
If anybody are curiuos or have any good ideas, the stacktrace I get is:
javax.ejb.TransactionRolledbackLocalException: EJB Exception:
- with nested exception:
[javax.ejb.EJBException
- with nested exception:
[weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion:
sync=weblogic.ejb20.internal.TxManager$TxListener@1c2906 - with nested exception:
[java.util.ConcurrentModificationException]]]
Start server side stack trace:
java.rmi.RemoteException: EJB Exception: ; nested exception is:
javax.ejb.TransactionRolledbackLocalException: EJB Exception:
- with nested exception:
[javax.ejb.EJBException
- with nested exception:
[weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion:
sync=weblogic.ejb20.internal.TxManager$TxListener@1c2906 - with nested exception:
[java.util.ConcurrentModificationException]]]
java.util.ConcurrentModificationException
at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:535)
at java.util.LinkedList$ListItr.next(LinkedList.java:476)
at weblogic.ejb20.manager.DBManager.beforeCompletion(DBManager.java:370)
at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManager.java:481)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:551)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:88)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:980)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1504)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:216)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:190)
at weblogic.ejb20.internal.BaseEJBLocalObject.postInvoke(BaseEJBLocalObject.java:207)
at com.takecargo.domainentities.role.RoleBean_1ipw6_ELOImpl.getName(RoleBean_1ipw6_ELOImpl.java:86)
at com.takecargo.domainentities.role.RoleConverter.getVOforRoleLocal(RoleConverter.java:51)
Any kind of help would be appreciated:)
Regards,
Brynjar Glesnes

Message Driven Bean and transaction handling

We are using container managed transactions with MDB's running on OC4J version 10.1.2. We have two database serveres, both running Oracle 10g.
The MDB consume messages from the AQ-database through JMS (connected to a JDBC datasource registered as "jdbc/OracleAQDS").
The MDB onMessage() code update the second database, using a JDBC datasource registered as "jdbc/OracleDBDS".
We need atomic behaviour - if the MDB enforce a roll-back we want the updates aginst the second database to be rolled-back as well.
(1) Should we use XA-datasources since AQ and DB runs on two different servers or do the OC4J container "magically" provide two-phase-commit for us?
(2) If the MDB does a roll-back we would like to add an error record to a database table. Can we configure a third datasource and prevent if from beeing part of the container managed MDB roll-back?
(3) When the MDB force a roll-back, is there some way for us to override the retry-delay in our Java code? If we catch certain errors during processing in onMessage we know that it is not necessary to retry for at least one hour (while less severe errors should be retried in just seconds).

{color:#008000}Hi Friends,
Thought of updating the answers for my questions in case somebody else would find it helpful.
{color}
{color:#999999}{color:#00ccff}I'm trying to make message driven bean and use the OnListener method.
But since I'm doing this for the first time I have very limited knowledge.
The following are my doubts :
1. Should I have a main function while using the MDB?{color}
{color:#008000} There is no need for any main function.{color}
{color:#00ccff}2. Is it mandatory to have JNDI setup done?
{color} {color}{color:#008000} There is no need for any JNDI setup done. But you need to configure the details on the
Websphere by creating valid entries inside Resources namely -
Queue Connection Factory, Queues and Listener Ports under the server.
Thanks,
Arun Prithviraj{color}

MDB container managed transaction demarcation not working in wls 6.1 beta

I have an MDB which sends the messages it receives onto another JMS
          destination within the onMessage method. These messages are not sent to
          the JMS destination unless I explicitly use a transacted session for the
          destination and subsequently commit the session. If I set the transacted
          parameter to Session as false the messages are sent. If I set the
          transacted parameter to true the messages will only be output if the
          session is committed. This is the standard behaviour for a JMS session
          but this is not the correct behaviour for an MDB running with
          container-managed transaction demarcation.
          For a start the transacted parameter to session should be ignored when
          run in the context of a container transaction and the commit method
          should thrown an exception as it is not allowed within the context of a
          container transaction.
          This is the MDB code and the deployment descriptor: -
          public class MessageBean implements MessageDrivenBean, MessageListener
          private String topicName = null;
          private TopicConnectionFactory topicConnectionFactory = null;
          private TopicConnection topicConnection = null;
          private TopicSession topicSession = null;
          private Topic topic = null;
          private TopicPublisher topicPublisher = null;
          private TextMessage textMessage=null;
          private transient MessageDrivenContext messageDrivenContext = null;
          private Context jndiContext;
          public final static String
          JMS_FACTORY="weblogic.examples.jms.TopicConnectionFactory";
          public final static String
          TOPIC="weblogic.examples.jms.exampleTopic";
          public MessageBean()
          public void setMessageDrivenContext(MessageDrivenContext
          messageDrivenContext)
          this.messageDrivenContext = messageDrivenContext;
          public void ejbCreate()
          public void onMessage(Message inMessage)
          try
          jndiContext = new InitialContext();
          topicConnectionFactory =
          (TopicConnectionFactory)jndiContext.lookup(JMS_FACTORY);
          topic = (Topic) jndiContext.lookup(TOPIC);
          topicConnection =
          topicConnectionFactory.createTopicConnection();
          topicConnection.start();
          // The transacted parameter should be ignored in the context of a
          container tx
          topicSession = topicConnection.createTopicSession(true,
          Session.AUTO_ACKNOWLEDGE);
          topicPublisher = topicSession.createPublisher(topic);
          textMessage = (TextMessage)inMessage;
          topicPublisher.publish(inMessage);
          // this is illegal in a container transaction
          topicSession.commit();
          topicConnection.close();
          catch (JMSException je)
          throw new EJBException(je);
          catch (NamingException ne)
          throw new EJBException(ne);
          public void ejbRemove()
          <?xml version="1.0" encoding="UTF-8"?>
          <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
          JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
          <ejb-jar>
          <enterprise-beans>
          <message-driven>
          <display-name>MessageBean</display-name>
          <ejb-name>MessageBean</ejb-name>
          <ejb-class>MessageBean</ejb-class>
          <transaction-type>Container</transaction-type>
          <message-driven-destination>
          <destination-type>javax.jms.Queue</destination-type>
          </message-driven-destination>
          <security-identity>
          <description></description>
          <run-as>
          <description></description>
          <role-name></role-name>
          </run-as>
          </security-identity>
          </message-driven>
          </enterprise-beans>
          <assembly-descriptor>
          <container-transaction>
          <method>
          <ejb-name>MessageBean</ejb-name>
          <method-name>*</method-name>
          </method>
          <trans-attribute>Required</trans-attribute>
          </container-transaction>
          </assembly-descriptor>
          </ejb-jar>


Please see the response in the EJB newsgroup.
          Also, could you kindly only post to a single newsgroup?
          Thanks.
          "Jimmy Johns" <[email protected]> wrote in message
          news:[email protected]...
          > I have an MDB which sends the messages it receives onto another JMS
          > destination within the onMessage method. These messages are not sent to
          > the JMS destination unless I explicitly use a transacted session for the
          >
          > destination and subsequently commit the session. If I set the transacted
          >
          > parameter to Session as false the messages are sent. If I set the
          > transacted parameter to true the messages will only be output if the
          > session is committed. This is the standard behaviour for a JMS session
          > but this is not the correct behaviour for an MDB running with
          > container-managed transaction demarcation.
          >
          > For a start the transacted parameter to session should be ignored when
          > run in the context of a container transaction and the commit method
          > should thrown an exception as it is not allowed within the context of a
          > container transaction.
          >
          > This is the MDB code and the deployment descriptor: -
          >
          > public class MessageBean implements MessageDrivenBean, MessageListener
          > {
          > private String topicName = null;
          > private TopicConnectionFactory topicConnectionFactory = null;
          > private TopicConnection topicConnection = null;
          > private TopicSession topicSession = null;
          > private Topic topic = null;
          > private TopicPublisher topicPublisher = null;
          > private TextMessage textMessage=null;
          > private transient MessageDrivenContext messageDrivenContext = null;
          >
          > private Context jndiContext;
          >
          > public final static String
          > JMS_FACTORY="weblogic.examples.jms.TopicConnectionFactory";
          > public final static String
          > TOPIC="weblogic.examples.jms.exampleTopic";
          >
          > public MessageBean()
          > {
          > }
          >
          > public void setMessageDrivenContext(MessageDrivenContext
          > messageDrivenContext)
          > {
          > this.messageDrivenContext = messageDrivenContext;
          > }
          >
          > public void ejbCreate()
          > {
          > }
          >
          > public void onMessage(Message inMessage)
          > {
          > try
          > {
          > jndiContext = new InitialContext();
          > topicConnectionFactory =
          > (TopicConnectionFactory)jndiContext.lookup(JMS_FACTORY);
          > topic = (Topic) jndiContext.lookup(TOPIC);
          > topicConnection =
          > topicConnectionFactory.createTopicConnection();
          > topicConnection.start();
          > // The transacted parameter should be ignored in the context of a
          > container tx
          > topicSession = topicConnection.createTopicSession(true,
          > Session.AUTO_ACKNOWLEDGE);
          > topicPublisher = topicSession.createPublisher(topic);
          > textMessage = (TextMessage)inMessage;
          > topicPublisher.publish(inMessage);
          > // this is illegal in a container transaction
          > topicSession.commit();
          > topicConnection.close();
          > }
          > catch (JMSException je)
          > {
          > throw new EJBException(je);
          > }
          > catch (NamingException ne)
          > {
          > throw new EJBException(ne);
          > }
          > }
          >
          > public void ejbRemove()
          > {
          > }
          > }
          >
          >
          >
          >
          > <?xml version="1.0" encoding="UTF-8"?>
          >
          > <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
          > JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
          >
          > <ejb-jar>
          > <enterprise-beans>
          > <message-driven>
          > <display-name>MessageBean</display-name>
          > <ejb-name>MessageBean</ejb-name>
          > <ejb-class>MessageBean</ejb-class>
          > <transaction-type>Container</transaction-type>
          > <message-driven-destination>
          > <destination-type>javax.jms.Queue</destination-type>
          > </message-driven-destination>
          > <security-identity>
          > <description></description>
          > <run-as>
          > <description></description>
          > <role-name></role-name>
          > </run-as>
          > </security-identity>
          > </message-driven>
          > </enterprise-beans>
          > <assembly-descriptor>
          > <container-transaction>
          > <method>
          > <ejb-name>MessageBean</ejb-name>
          > <method-name>*</method-name>
          > </method>
          > <trans-attribute>Required</trans-attribute>
          > </container-transaction>
          > </assembly-descriptor>
          > </ejb-jar>
          >
          >
          >
          >
          >
          >
          >
          >

Bean Managed Transactions

Similar Messages

Maybe you are looking for