Cannot commit during managed transaction - MDB

Hi
I use message-driven bean to asynchronously send newsletters. To avoid restarting process from the beginning in case of any error, I save the recipients in database table, and remove row by row after email has been sent. To not mark my mail server as spammer I send it in chunks of 90 per minute. My recipients list is quite big, about 30k addresses. The code works perfect, but only few minutes... Then transaction is timed out, deleting of already sent recipients is not commited and the process begins again! That of course results in delivering the same message multiple times to the same recipients.
I tried setting autocommit to false and forcing commit before thread going sleep, but I kept getting error "cannot commit managed transaction".
Can anybody help?
Michal
            int sentCount = 0;
            con = locator.getPGDataSource().getConnection();           
            PreparedStatement stmt = con.prepareStatement("SELECT * " +
                    "FROM mail_recipient " +
                    "WHERE task_id = ? " +
                    "ORDER BY id ASC " +
                    "LIMIT " + CHUNK_SIZE + " ");
            stmt.setInt(1, Integer.parseInt(id));
            ResultSet rs = stmt.executeQuery();
            StringBuffer sentIds = new StringBuffer();
            while(rs.next()) {
                if(!checkInProgressStatus(file))
                    return;
                email = rs.getString("email");
                String from_address = getMailProperty(account, "mail");
                String display_name = getMailProperty(account, "display_name");
                InternetAddress inetAddr = new InternetAddress(from_address,
                        display_name);
                Mail mail = new Mail(inetAddr,
                        getMailProperty(account, "username"),
                        getMailProperty(account, "password"));
                try {
                    mail.sendEmail(email, subject, content);
                } catch (MessagingException ex) {
                    log.error("Cannot send to: " + email + " - user " + rs.getInt("customer_id"));
                sentIds.append(rs.getInt("id") + ",");               
                if(++sentCount % CHUNK_SIZE == 0) {
                    try {
                        try {
                            rs.close();
                            stmt.close();
                            con.close();
                        } catch (SQLException ex) {                           
                        Connection con2 = null;
                        con2 = locator.getPGDataSource().getConnection();
                        PreparedStatement stmt2 =
                                con2.prepareStatement("DELETE FROM mail_recipient " +
                                "WHERE id IN(" +
                                sentIds.substring(0, sentIds.length()-1) + ")");
                        stmt2.executeUpdate();
                        sentIds = new StringBuffer();
                        stmt2 = con2.prepareStatement("SELECT COUNT(*) " +
                                "FROM mail_recipient " +
                                "WHERE task_id = ?");
                        stmt2.setInt(1, Integer.parseInt(id));
                        ResultSet rs2 = stmt2.executeQuery();
                        rs2.next();
                        int count = rs2.getInt(1);
                        log.error(count + "");
                        taskNode.setAttribute("recipients_left", count + "");
                        saveXML(doc, file);
                        try {
                            rs2.close();
                            stmt2.close();
                            con2.close();
                        } catch (SQLException ex) {
                        Thread.sleep(60*1000);
                    } catch (InterruptedException ex) {
                    con = locator.getPGDataSource().getConnection();                  
                    stmt = con.prepareStatement("SELECT * " +
                            "FROM mail_recipient " +
                            "WHERE task_id = ? " +                           
                            "ORDER BY id ASC " +
                            "LIMIT " + CHUNK_SIZE + " ");
                    stmt.setInt(1, Integer.parseInt(id));
                    rs = stmt.executeQuery();
            }

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

Similar Messages

  • 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

  • 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

  • Container Managed Transaction + MDB

    A typical scenario where MDB calls Session Beans. If I want to use CMT on MDB, why is it required that XAConnectionFactory be used? I need my database update to be controlled by CMT not the message delivery?
              Again, when using XAConn.., it asks to use two-phase commit. Is this because there are two resources involved -first the datasource and other the jmsconnection factory.
              ?

    A typical scenario where MDB calls Session Beans. If I want to use CMT on MDB, why is it required that XAConnectionFactory be used? I need my database update to be controlled by CMT not the message delivery?
              Again, when using XAConn.., it asks to use two-phase commit. Is this because there are two resources involved -first the datasource and other the jmsconnection factory.
              ?

  • 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:
    <!-- Passport CMT DataSource -->
    <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.

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

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

  • Oracle.xml.sql.OracleXMLSQLException:Cannot enable auto commit within JTS transaction

    Hi All,
    OracleXMLSave class in the Oracle XDK is being used to load XML data into an 8170 database. The Java code is running in IBM WebSphere with container-managed transactions. When JTA is enabled with the Merant JDBC driver for Oracle, we get the following error when the XML is loaded:
    oracle.xml.sql.OracleXMLSQLException: Cannot enable auto commit within JTS
    transaction
         at java.lang.Throwable.fillInStackTrace(Native Method)
         at oracle.xml.sql.dml.OracleXMLSave.saveXML(OracleXMLSave.java:2213)
         at oracle.xml.sql.dml.OracleXMLSave.insertXML(Compiled Code)
    This suggests the OracleXMLSave class is not aware of the fact that it is now operating in a JTS transaction where control is managed elsewhere. i.e. should also not attempt to commit or rollback, as this is the responsibility of the container.
    Is there a property which needs to set to prevent the above or does the XDK not work with J2EE (JTS) transactions?.
    If you have any useful comments, let me know. Testing the above presents me with a number of problems so if this is easily explained , let me know.
    Thanks,
    Malcolm

    Clearly , there does seem to be something a bit odd with the above stack.
    <Bug:1917808> mentions OracleXMLSave in context of plsql equivalent : dbms_xmlsave . i.e dbms_xmlsave is a wrapper around OracleXMLSave class.
    disabling autocommit on connection as follows should help:
    conn = DriverManager.getConnection("connect string","scott","tiger");
    conn.setAutoCommit(false);
    to disble auto commit and see if this has an effect.
    This issue might be <Bug:1497506>. If disabling autocommit does not work then it appears that it could be this issue .
    Malcolm
    Hi All,
    OracleXMLSave class in the Oracle XDK is being used to load XML data into an 8170 database. The Java code is running in IBM WebSphere with container-managed transactions. When JTA is enabled with the Merant JDBC driver for Oracle, we get the following error when the XML is loaded:
    oracle.xml.sql.OracleXMLSQLException: Cannot enable auto commit within JTS
    transaction
         at java.lang.Throwable.fillInStackTrace(Native Method)
         at oracle.xml.sql.dml.OracleXMLSave.saveXML(OracleXMLSave.java:2213)
         at oracle.xml.sql.dml.OracleXMLSave.insertXML(Compiled Code)
    This suggests the OracleXMLSave class is not aware of the fact that it is now operating in a JTS transaction where control is managed elsewhere. i.e. should also not attempt to commit or rollback, as this is the responsibility of the container.
    Is there a property which needs to set to prevent the above or does the XDK not work with J2EE (JTS) transactions?.
    If you have any useful comments, let me know. Testing the above presents me with a number of problems so if this is easily explained , let me know.
    Thanks,
    Malcolm

  • MDB Container Managed Transaction and Log4J

    Hi,
    I'm programming and MDB that reads and updates a database then sends out an HTTP Post and logs using log4j. I've read that when an MDB is configured as CMT or container managed transaction and the OnMessage method executes without errors, the transaction is implicitly commited. You can rollback the transaction by explicitly calling setRollbackOnly() or when a RuntimeException has been thrown. My worry is that after I have sent out an HTTP POST (a transaction has been completed) I would have to log a transaction completion using log4j. My problems is if log4j throws a RuntimeException thereby rolling back my transaction which shouldn't be the case. What I have done is to catch all Exceptions (and swallow them) whenever I log using log4j after I have sent out an HTTP POST succesfully (since my transaction should be complete by then). Is this a correct workaround?
    Thanks :)

    Your approach is correct. If you think, Log4J might throw errors, swallow the exceptions and try not to roll back.

  • Cannot change transaction isolation during distributed transaction

    Hi All,
    When ever the IPortalComponent session expires my application is throwing Null pointer exception. So I am catching the NullPointer exception and then reloading the page again. It is working in frontend without any issues.
    But in the error log monitor(nwa) I can see the below error when reloading the page after component session expires.
    Cannot change transaction isolation during distributed transaction and when the connection is shared. DataSource name: "PRODB2
    As per my knowledge I understood that this is happening beacuse application is trying to recreate a new connection pool while one pool instance is alive.
    If this is correct can any one tell me how to destory the pool of current session when reloading the page.
    Thanks in Advance,
    Chinna.

    What was the solution to the problem ?

  • No externally managed transaction is currently active for this thread

    Got the following exception after updating an entity bean and call persist method. Code the given below the exception.
    Exception [TOPLINK-23010] (Oracle TopLink - 10g Release 3 (10.1.3.0.0) (Build 060118)): oracle.toplink.exceptions.TransactionException
    Exception Description: No externally managed transaction is currently active for this thread
    public Object persistEntity(Object entity) {
    em.flush();
    em.persist(entity);
    return entity;
    private void modifyUser (Iuser user, String newHandle, Hashtable userDetails) throws UnknownException, WarningException {
    if (user == null) {
    throw new WarningException (new CatalogHelper("ITOOLS_000015", "to modify a user"));
    boolean handleUpdate = false;
    if ((newHandle != null) && !newHandle.equals("^\\s*$")) {
    handleUpdate = true;
    String oldHandle = user.getUserhandle();
    if (handleUpdate && oldHandle.equalsIgnoreCase(newHandle)) {
    handleUpdate = false;
    if (!handleUpdate && (userDetails == null) || (userDetails.size() == 0)) {
    return;
    if (handleUpdate) {
    userDetails.put("userhandle", newHandle);
    IToolsUtil.validateInputData("iuser", userDetails, false);
    if (handleUpdate) {
    userDetails.remove("userhandle");
    System.out.println("handleUpdate " + handleUpdate);
    // For User admin, handle, isactive, isadmin cannot be changed.
    if (oldHandle.equals("admin")) {
    if (handleUpdate) {
    throw new WarningException (new CatalogHelper("ITOOLS_000045", "Handle"));
    String active = (String)userDetails.get("isactive");
    if ((active != null) && !active.equals("Yes")) {
    throw new WarningException (new CatalogHelper("ITOOLS_000045", "Is Active"));
    String admin = (String)userDetails.get("isadmin");
    if ((admin != null) && !admin.equals("Yes")) {
    throw new WarningException (new CatalogHelper("ITOOLS_000045", "Is Admin"));
    System.out.println("user transaction started");
    if (handleUpdate) {
    FinderMethods fm = new FinderMethods();
    try {
    fm.findByUserHandle(em, newHandle);
    throw new WarningException (new CatalogHelper("ITOOLS_000043", newHandle));
    } catch (ObjectNotFoundException onfe) {
    user.setUserhandle(newHandle);
    System.out.println("User handle modified");
    } catch (SQLException se) {
    se.printStackTrace();
    throw new UnknownException (new CatalogHelper("ITOOLS_100000", new Object[]{"modifyUser", se.getMessage()}));
    String lname = (String)userDetails.get("userlname");
    if (lname != null) {
    user.setUserlname(lname);
    String fname = (String)userDetails.get("userfname");
    if (fname != null) {
    user.setUserfname(fname);
    String email = (String)userDetails.get("useremail");
    if (email != null) {
    user.setUseremail(email);
    String passwd = (String)userDetails.get("userpasswd");
    if (passwd != null) {
    user.setUserpasswd(passwd);
    String active = (String)userDetails.get("isactive");
    if (active != null) {
    user.setIsactive(active);
    String admin = (String)userDetails.get("isadmin");
    if (admin != null) {
    user.setIsactive(admin);
    System.out.println("details are updated");
    persistEntity(user);
    System.out.println("committed");
    How to resolve this issue? I am using Jdeveloper 10.1.3.0.4 (SU4)
    regds
    -raju

    The stack trace is given below. This exception is occured at "em.flush()" method. I even tried removing em.flush() method. Even then I got the same exception.
    I tried a different way of overcome this problem. Used UserTransaction instance say "ut" before create / modify the entity bean and later comitted. In that case I am not getting any exceptions. However, commit is happening only when new instance is created, commit works, but modification of an existing instance, commit is not working. Looks like there is some serious problem with EJB 3.0 in OC4J. Basic functionality is not working.
    Stack trace when flush method is called:
    Local Exception Stack:
    Exception [TOPLINK-23010] (Oracle TopLink - 10g Release 3 (10.1.3.0.0) (Build 060118)): oracle.toplink.exceptions.TransactionException
    Exception Description: No externally managed transaction is currently active for this thread
         at oracle.toplink.exceptions.TransactionException.externalTransactionNotActive(TransactionException.java:98)
         at oracle.toplink.internal.ejb.cmp3.transaction.base.JTATransactionWrapper.checkForTransaction(JTATransactionWrapper.java:39)
         at oracle.toplink.internal.ejb.cmp3.base.EntityManagerImpl.checkForTransaction(EntityManagerImpl.java:322)
         at oracle.toplink.internal.ejb.cmp3.base.EntityManagerImpl.getActiveUnitOfWork(EntityManagerImpl.java:314)
         at oracle.toplink.internal.ejb.cmp3.base.EntityManagerImpl.flush(EntityManagerImpl.java:164)
         at com.itools.vs.model.session.AdminSessionBean.persistEntity(AdminSessionBean.java:57)
         at com.itools.vs.model.session.AdminSessionBean.createUser(AdminSessionBean.java:124)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)
    Stack trace when persist method is called:
    Local Exception Stack:
    Exception [TOPLINK-23010] (Oracle TopLink - 10g Release 3 (10.1.3.0.0) (Build 060118)): oracle.toplink.exceptions.TransactionException
    Exception Description: No externally managed transaction is currently active for this thread
         at oracle.toplink.exceptions.TransactionException.externalTransactionNotActive(TransactionException.java:98)
         at oracle.toplink.internal.ejb.cmp3.transaction.base.JTATransactionWrapper.checkForTransaction(JTATransactionWrapper.java:39)
         at oracle.toplink.internal.ejb.cmp3.base.EntityManagerImpl.checkForTransaction(EntityManagerImpl.java:322)
         at oracle.toplink.internal.ejb.cmp3.base.EntityManagerImpl.getActiveUnitOfWork(EntityManagerImpl.java:314)
         at oracle.toplink.internal.ejb.cmp3.base.EntityManagerImpl.persist(EntityManagerImpl.java:74)
         at com.itools.vs.model.session.AdminSessionBean.persistEntity(AdminSessionBean.java:57)
         at com.itools.vs.model.session.AdminSessionBean.createUser(AdminSessionBean.java:123)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)

  • Executing SQL statements in container managed transactions

    I have a problem when using TopLink 9.0.3 with WebSphere 4, Oracle 9i and J2EE container managed transactions.
    The data changing SQL statements are executed at the end of the (container managed) transaction, not at the time of the calls to UnitOfWork.registerNewObjekt(),
    UnitOfWork.validate...() or UnitOfWork.commit...().
    UnitOfWork(2035008996)--validate object space.
    UnitOfWork(2035008996)--validate cache.
    UnitOfWork(2035008996)--JTS#beforeCompletion()
    UnitOfWork(2035008996)--Connection(398132708)--INSERT INTO SVM_PERSONEN (FAX, NAME, ID, [...]) VALUES ([...])
    UnitOfWork(2035008996)--JTS#afterCompletion(org.omg.CosTransactions.Status._StatusRolledBack=4)
    UnitOfWork(2035008996)--release unit of work
    But the end of the transaction is out of the application server code. The transaction ends after the invoke of the applixcation server method, as the stack trace of an occurring exception shows:
    remote exception
    javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0 No; nested exception is:
         org.omg.CORBA.TRANSACTION_ROLLEDBACK:
    org.omg.CORBA.TRANSACTION_ROLLEDBACK: com.ibm.websphere.csi.CSITransactionRolledbackException:
         at com.ibm.ejs.csi.TranStrategy.commit(TranStrategy.java:194)
         at com.ibm.ejs.csi.TranStrategy.postInvoke(TranStrategy.java:67)
         at com.ibm.ejs.csi.TransactionControlImpl.postInvoke(TransactionControlImpl.java:414)
         at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:1818)
         at de.gedas.svm.server.app.ejb.EJSRemoteStatelessNavigationEJB.findPersonenZulieferer(EJSRemoteStatelessNavigationEJB.java:964)
         at de.gedas.svm.server.app.ejb._EJSRemoteStatelessNavigationEJB_Tie._invoke(_EJSRemoteStatelessNavigationEJB_Tie.java:589)
         at com.ibm.CORBA.iiop.ExtendedServerDelegate.dispatch(ExtendedServerDelegate.java:506)
         at com.ibm.CORBA.iiop.ORB.process(ORB.java:2376)
         at com.ibm.CORBA.iiop.OrbWorker.run(OrbWorker.java:186)
         at com.ibm.ejs.oa.pool.ThreadPool$PooledWorker.run(ThreadPool.java:104)
         at com.ibm.ws.util.CachedThread.run(ThreadPool.java:137)
    So the application server code has no possiblity for special reaction to this error condition.
    How can I use TopLink to execute my SQL statement immidately, not at the the end of the transaction (which is out of the area of my code)? Only the transaction should end at the usual time, managed by the container.

    I don't think there is anyway to currently do this in a JTS managed environment, to handle the exceptions you could,
    - Make use of TopLink session ExceptionHandlers to handle the database errors during the JTS commit.
    i.e.
    uow.setExceptionHandler(yourExceptionHandler);
    or,
    - Let TopLink control the transactions instead of JTS.

  • Error: cannot commit (when inserting the row)

    hai,
    I create the trigger like below.
    create or replace trigger proce
    after insert on samp3
    declare
    ass date;
    begin
    select d into ass from samp3;
    updatecourse(ass);
    end;
    when I try to insert the row then the error is come;
    ERROR at line 1:
    ORA-20001: An error was encountered - -4092 -ERROR- ORA-04092: cannot COMMIT in a trigger
    ORA-06512: at "AUROLIVE.UPDATECOURSE", line 22
    ORA-06512: at "AUROLIVE.PROCE", line 5
    ORA-04088: error during execution of trigger 'AUROLIVE.PROCE'
    can any one help me?
    Regards,
    Ramya.S

    If u want to put commit on trigger use pragma
    autonomous_transaction.what it does,it leave the main
    transaction and commit the second transaction.Which can lead to logic problems and corruption of your business data if not used extremely carefully.
    If you start transaction 1 and during that write some other data as transaction 2 using autonomous transactions and then subsequently find that there is an error or some reason not to commit transaction 1 then you cannot automatically roll back transaction 2 and would have to take care of it manually.
    I see too many occurences of developers using autonomous transaction all over the place just because they want to get the data written to the database and then they're wondering why there is so much clutter in their data and the database integrity is poor from a business/logical point of view. The first thing any good design includes is a knowledge of the business transactions and when data should be committed and what the implications of using autonomous transactions are.

  • Setting auto-commit inside a transaction

    I am trying Kodo 2.4 RC3 with JBoss 3.0.4 and Hypersonic SQL DB
    1.7.1b (in server mode) on Mac OS X 10.2.2 and get the exception listed
    below. I understand that the autocommit property of the database
    connections should be off in order to avoid this error, but how can I
    achieve this?
    [java] java.sql.SQLException: You cannot set autocommit during a
    managed transaction!
    [java] at
    org.jboss.resource.adapter.jdbc.local.LocalManagedConnection.setJdbcAutoCommit(LocalManagedConnection.java:447)
    [java] at
    org.jboss.resource.adapter.jdbc.local.LocalConnection.setAutoCommit(LocalConnection.java:426)
    [java] at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.getConnection(SQLExecutionManagerImpl.java:149)
    [java] at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.prepareStatementInternal(SQLExecutionManagerImpl.java:805)
    [java] at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executePreparedQueryInternal(SQLExecutionManagerImpl.java:760)
    [java] at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executeQueryInternal(SQLExecutionManagerImpl.java:692)
    [java] at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executeQuery(SQLExecutionManagerImpl.java:373)
    [java] at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executeQuery(SQLExecutionManagerImpl.java:357)
    [java] at
    com.solarmetric.kodo.impl.jdbc.ormapping.SubclassProviderImpl.getSubclasses(SubclassProviderImpl.java:231)
    [java] at
    com.solarmetric.kodo.impl.jdbc.ormapping.ClassMapping.getPrimaryMappingFields(ClassMapping.java:1093)
    [java] at
    com.solarmetric.kodo.impl.jdbc.ormapping.ClassMapping.loadByPK(ClassMapping.java:931)
    [java] at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.initialize(JDBCStoreManager.java:263)
    [java] at
    com.solarmetric.kodo.runtime.StateManagerImpl.loadInitialState(StateManagerImpl.java:174)
    [java] at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.getObjectByIdFilter(PersistenceManagerImpl.java:986)
    [java] at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:888)
    [java] at
    im.jdo.JDOWorker$IssueWorker.getIssue(JDOWorker.java:952)
    [java] at
    im.jdo.JDOWorker$IssueWorker.getIssue(JDOWorker.java:810)
    [java] at
    im.jdo.JDOWorker$IssueWorker.access$2400(JDOWorker.java:789)
    [java] at im.jdo.JDOWorker.getIssue(JDOWorker.java:1089)
    [java] at im.jdo.JDOWorker.getIssue(JDOWorker.java:1079)
    [java] at
    im.ejb.impl.MeisterSessionBean.getIssue(MeisterSessionBean.java:280)
    [java] at java.lang.reflect.Method.invoke(Native Method)
    [java] at
    org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invoke(StatefulSessionContainer.java:817)
    [java] at
    org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
    [java] at
    org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
    [java] at
    org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:268)
    [java] at
    org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107)
    [java] at
    org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:178)
    [java] at
    org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60)
    [java] at
    org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204)
    [java] at
    org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:380)
    [java] at org.jboss.ejb.Container.invoke(Container.java:712)
    [java] at
    org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
    [java] at
    org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382)
    [java] at java.lang.reflect.Method.invoke(Native Method)
    [java] at
    sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236)
    [java] at sun.rmi.transport.Transport$1.run(Transport.java:147)
    [java] at java.security.AccessController.doPrivileged(Native
    Method)
    [java] at
    sun.rmi.transport.Transport.serviceCall(Transport.java:143)
    [java] at
    sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
    [java] at
    sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
    [java] at java.lang.Thread.run(Thread.java:491)

    Jakob,
    That's a good question. I don't have much experience with HSQLDB and
    JBoss, but I imagine that there's a configuration option somewhere
    that's setting autocommit to true. We only try to set autocommit to
    false if we see that it's set to true (by invoking conn.getAutoCommit()).
    What do your HSQL properties look like? Do you get any hits when running
    'grep -ri autocommit /path/to/jboss' from a terminal window?
    -Patrick
    Jakob Spies wrote:
    I am trying Kodo 2.4 RC3 with JBoss 3.0.4 and Hypersonic SQL DB
    1.7.1b (in server mode) on Mac OS X 10.2.2 and get the exception listed
    below. I understand that the autocommit property of the database
    connections should be off in order to avoid this error, but how can I
    achieve this?
    [java] java.sql.SQLException: You cannot set autocommit during a
    managed transaction!
    [java] at
    org.jboss.resource.adapter.jdbc.local.LocalManagedConnection.setJdbcAutoCommit(LocalManagedConnection.java:447)
    [java] at
    org.jboss.resource.adapter.jdbc.local.LocalConnection.setAutoCommit(LocalConnection.java:426)
    [java] at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.getConnection(SQLExecutionManagerImpl.java:149)
    [java] at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.prepareStatementInternal(SQLExecutionManagerImpl.java:805)
    [java] at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executePreparedQueryInternal(SQLExecutionManagerImpl.java:760)
    [java] at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executeQueryInternal(SQLExecutionManagerImpl.java:692)
    [java] at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executeQuery(SQLExecutionManagerImpl.java:373)
    [java] at
    com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executeQuery(SQLExecutionManagerImpl.java:357)
    [java] at
    com.solarmetric.kodo.impl.jdbc.ormapping.SubclassProviderImpl.getSubclasses(SubclassProviderImpl.java:231)
    [java] at
    com.solarmetric.kodo.impl.jdbc.ormapping.ClassMapping.getPrimaryMappingFields(ClassMapping.java:1093)
    [java] at
    com.solarmetric.kodo.impl.jdbc.ormapping.ClassMapping.loadByPK(ClassMapping.java:931)
    [java] at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.initialize(JDBCStoreManager.java:263)
    [java] at
    com.solarmetric.kodo.runtime.StateManagerImpl.loadInitialState(StateManagerImpl.java:174)
    [java] at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.getObjectByIdFilter(PersistenceManagerImpl.java:986)
    [java] at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:888)
    [java] at
    im.jdo.JDOWorker$IssueWorker.getIssue(JDOWorker.java:952)
    [java] at
    im.jdo.JDOWorker$IssueWorker.getIssue(JDOWorker.java:810)
    [java] at
    im.jdo.JDOWorker$IssueWorker.access$2400(JDOWorker.java:789)
    [java] at im.jdo.JDOWorker.getIssue(JDOWorker.java:1089)
    [java] at im.jdo.JDOWorker.getIssue(JDOWorker.java:1079)
    [java] at
    im.ejb.impl.MeisterSessionBean.getIssue(MeisterSessionBean.java:280)
    [java] at java.lang.reflect.Method.invoke(Native Method)
    [java] at
    org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invoke(StatefulSessionContainer.java:817)
    [java] at
    org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
    [java] at
    org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
    [java] at
    org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:268)
    [java] at
    org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107)
    [java] at
    org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:178)
    [java] at
    org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60)
    [java] at
    org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204)
    [java] at
    org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:380)
    [java] at org.jboss.ejb.Container.invoke(Container.java:712)
    [java] at
    org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
    [java] at
    org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382)
    [java] at java.lang.reflect.Method.invoke(Native Method)
    [java] at
    sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236)
    [java] at sun.rmi.transport.Transport$1.run(Transport.java:147)
    [java] at java.security.AccessController.doPrivileged(Native
    Method)
    [java] at
    sun.rmi.transport.Transport.serviceCall(Transport.java:143)
    [java] at
    sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
    [java] at
    sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
    [java] at java.lang.Thread.run(Thread.java:491)
    Patrick Linskey [email protected]
    SolarMetric Inc. http://www.solarmetric.com

  • EJB conainer-managed transaction commits too late

    I implemented a stateless session bean which performs a set of insertions into an Oracle database. Afterwards, the session bean sends a message to a JMS queue for auditing purposes. On the other side of the JMS queue, there is an MDB that is waiting for messages and, after receiving a message, the MDB is supposed to perform updates on the previous insertions.
    The problem is that the MDB is not reading the changes previously done by the session bean. The container-managed transaction executed on the session bean does not seem to have commited its changes when the MDB is executing its logic.
    The transaction attributes for the session bean and the MDB are Required and NotSupported, respectively. Furthermore, the session bean sends messages to the JMS queue using transacted JMS sessions (commit() is explicitly called at the end of the session). Oddly, when the transaction attribute for the MDB is changed to Required, the MDB freezes and therefore reads nothing.
    I need the MDB to receive messages only when the previous transaction has already been committed.
    Any hint to this problem will be appreciated.

    Hi,
    The problem here is that you have set the transaction attribute of session bean as Required and MDB's as NotSupported".So when the message is put onto the queue the transcaction of Session bean is still running and the MDB suspends the transaction of the session bean and hence you will not be able to get the inserted records.
    According to me the Required as the transaction attribute of the MDB it should work fine.
    Hope this helps...
    Bhagya

Maybe you are looking for