Problem in WEblogic10.3 EJB transaction rollbacked

Hi,
I was using a web application which was working on weblogic 8.1.3. Now we are trying to move this application to weblogic10.3. But i am getting following error message on the log. application seems working fine. but weblogic console is running endlessly displaying errors. Log i checked this is what it contains. could anyone tell me what the error could be.
####<Nov 8, 2008 6:00:47 PM IST> <Info> <EJB> <swetha> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1226147447779> <BEA-010213> <Message-Driven EJB: AbsenceEventBean's transaction was rolled back. The transaction details are: Xid=BEA1-00FE2B90928387325B62(15448115),Status=Rolled back. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=60,XAServerResourceInfo[WLStore_mydomain_managed_aam1]=(ServerResourceInfo[WLStore_mydomain_managed_aam1]=(state=rolledback,assigned=AdminServer),xar=WLStore_mydomain_managed_aam127545119,re-Registered = false),XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=rolledback,assigned=AdminServer),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@ebc0b4,re-Registered = false),XAServerResourceInfo[jtsRmopPool]=(ServerResourceInfo[jtsRmopPool]=(state=rolledback,assigned=AdminServer),xar=jtsRmopPool,re-Registered = false),SCInfo[mydomain+AdminServer]=(state=rolledback),properties=({weblogic.jdbc=t3://172.21.20.131:7001}),local properties=({weblogic.jdbc.jta.jtsRmopPool=[ No XAConnection is attached to this TxInfo ]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=AdminServer+172.21.20.131:7001+mydomain+t3+, XAResources={jtsRmopPool, WLStore_mydomain_managed_aam1, WLStore_mydomain_FileStore, WLStore_mydomain__WLS_AdminServer, weblogic.jdbc.wrapper.JTSXAResourceImpl},NonXAResources={})],CoordinatorURL=AdminServer+172.21.20.131:7001+mydomain+t3+).>
Any kind of help would be greatly appreciated.
Thanking you,
Regards,
Neeraj

Yes, the message you are seeing is a informational message displayed by weblogic. It means that the transaction was rolled back by the mdb container. The bean name is "AbsenceEventBean" seen in the info message.It seems that code has invoked context.setRollbackOnly(),that causes the CMT to rollback. If this application is not running in prodcution mode, then you can enable EJB and JTA debug and analyze the reasons for the rollback of the transaction.
Edited by: mchellap on Nov 9, 2008 6:15 AM

Similar Messages

  • JDBC, JMS and EJB transactions - possible problem?

    Hello,
              I am using Oracle 9, Weblogic 8.1 SP 4, MyEclipse and
              XDoclet.
              In my current project I have the following piece of code
              in one of my message driven beans (code cited as pseudocode
              without unnecessary details):
              * @ejb.bean name="MyMessageProcessor"
              * display-name="Display name for a MyMessageProcessor"
              * jndi-name="ejb/MyMessageProcessor"
              * description="Bean MyMessageProcessor"
              * destination-type="javax.jms.Queue"
              * transaction-type="Container"
              * acknowledge-mode="Auto-acknowledge"
              * subscription-durability="Durable"
              * generate="false"
              * @ejb.transaction type="Required"
              public class MyMessageProcessor implements MessageDrivenBean, MessageListener {
              public void onMessage(Message msg) {
                   try {
                        //obtaining connections to two different databases via JNDi
                        java.sql.Connection connOne =
                        ((DataSource)ctx.lookup("DataSourceOne")).getConnection();          
                        java.sql.Connection connTwo =
                             ((DataSource)ctx.lookup("DataSourceTwo")).getConnection();
                        // performing some UPDATEs and INSERTs on connOne and connTwo
                        // calling some other methods of this bean
                        //creating the reply JMS message and sending it to another JMS queue
                        Message msgTwo = this.createReplyMessage(msg)
                        this.queueSender.send(msgTwo);
                        //commiting everything
                        this.queueSession.commit();          
                   } catch (Exception ex) {
                   try {
                        if (this.queueSession!=null) this.queueSession.rollback();
                   } catch (JMSException JMSEx) {};     
                   this.context.setRollbackOnly();
              Some days ago (before the final remarks from my client) there used to be only one DataSource configurated on the basis of the
              connection pool with non-XA jdbc driver. Everything worked fine
              including the transactions (if anything wrong happend not only wasn't the replymessage sent, but also no changes were written
              to database and the incomming message was thrown back to the my bean's
              queue).
              When I deployed the second DataSource I was informed by an error message, that only one non-transactional resource may
              participate in a global transaction. When I changed both datasources
              to depend on underlying datasources with transatcional (XA) jdbc drivers, everything stopped working. Even if
              EJB transaction was theoretically successfully rolledbacked, the changed were written to the database
              and the JMS message wasn't resent to the JMS queue.
              So here are my questions:
                   1. How to configure connection pools to work in such situations? What JDBC drivers should I choose?
                   Are there any global server configurations, which may influence this situation?
                   2. Which jdbc drivers should I choose so that the container was able to rollback the database transactions
                   (of course, if necessary)?
                   3. Are there any JMS Queue settings, which would disable the container to send message back to the
                   queue in case of setRollbackOnly()? How should be the Queue configurated?
              As I am new to the topic and the deadline for the project seems to be too close I would be grateful
              for any help.
              This message was sent to EJB list and JDBC list.
              Sincerely yours,
              Marcin Zakidalski

    Hi,
              I found these information extremely useful and helpful.
              The seperate transaction for sending messages was, of course, unintentional. Thanks a lot.
              Anyway, I still have some problems. I have made some changes to the
              code cited in my previous mail. These changes included changing QueueSessions
              to non-transactional. I also set the "Honorate global transactions" to true.
              I am using XA JDBC driver. After setting "Enable local transactions" to false
              (I did it, because I assume that JDBC transactions should be part on the global
              EJB transaction) I got the following error:
              java.sql.SQLException: SQL operations are not allowed with no global transaction by default for XA drivers. If the XA
              driver supports performing SQL operations with no global transaction, explicitly allow it by setting
              "SupportsLocalTransaction" JDBC connection pool property to true. In this case, also remember to complete the local
              transaction before using the connection again for global transaction, else a XAER_OUTSIDE XAException may result. To
              complete a local transaction, you can either set auto commit to true or call Connection.commit() or Connection.rollback().
              I have also inspected the calls of methods of bean inside of onMessage() method just to check, whether
              the transactions are correctly initialized (using the weblogic.transaction.Transaction class).
              My questions are as follows:
              1. Any suggestions how to solve it? I have gone through the google answers on that problem and only
              thing I managed to realize that JDBC must start its own transaction. Is there any way to prohibit it
              from doing that? Can using setAutocommit(true/false) change the situation for better?
              2. How to encourage the JDBC driver to be a part of EJB transaction?
              3. As I have noticed each of ejb method has its own transactions (transactions have different
              Xid). Each method of the bean has "required" transaction attribute. Shouldn't it work in such
              way that if already started transaction exists it is used by the called method?
              4. The DataSources are obtained in my application via JNDI and in the destination environment I will have slight
              impact on the configuration of WebLogic. What is least problematic and most common WebLogic configuration which would
              enable JDBC driver to participate in the EJB transaction? Is it the WebLogic configuration problem or can it be
              solved programmically?
              Currently my module works quite fine when "enable local transactions" for DataSources is set to true, but this way
              I am loosing the ability to perform all actions in one transaction.
              Any suggestions / hints are more than welcomed. This message was posted to jdbc list and ejb list.
              Marcin

  • Transaction rollback or commit

    Hello to everybody...I'd need a solution for a probem that I 'm not able to resolve.I have a session bean on the server ( WeblogicServer 8.1 Sp3 ) and a Java Swing client.I need to break and rollback a long process on the server by client swing button pression.I have thought to create a user transaction (under a client thread process) on the client and I try to propagate it to the container ( Container Managed Transaction).Now I have to break the long time server operation at certain moment by make a rollback on the client trasaction,after the button pression.The problem is that the rollback DOES NOT ARRIVE to the server and the sever process continue to operate.How this is possible?I think that I make basic mistake,but which?Can Anyone help me please?
    thanks for help and sorry for bad english.

    whaqt I need to do is to break and rollback the transaction ( REQUIRED on the container ) by the client when I want....Whit this prototipe now I try to pass the transaction rollback operation from the client to the server,bt now the message on the server is the following:
    java.sql.SQLException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 33 seconds
    Xid=BEA1-00006D5145365E026810(6407574),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=1,seconds since begin=33,seconds left=30,activeThread=Thread[ExecuteThread: '23' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=started,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@f30862,re-Registered = false),SCInfo[mydomain+IRMA_Admin]=(state=active),properties=({weblogic.jdbc=t3://10.2.1.16:10004}),CoordinatorURL=IRMA_Admin+10.2.1.16:10004+mydomain+t3+)]'. No further JDBC access is allowed within this transaction.
    at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:155)
    at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:164)
    at weblogic.jdbc.wrapper.Statement.checkStatement(Statement.java:234)
    at weblogic.jdbc.wrapper.Statement.preInvocationHandler(Statement.java:83)
    at weblogic.jdbc.wrapper.Statement_oracle_jdbc_driver_T4CStatement.clearBatch(Unknown Source)
    at irma.utility.database.DataBaseUtility.executeBatchUpdate(DataBaseUtility.java:62)
    at irma.technology.IrmaTechno.updateDBData(IrmaTechno.java:1077)
    at irma.business.service.ImportService.importFileEricsson(ImportService.java:698)
    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:324)
    at irma.business.Dispatcher.callService(Dispatcher.java:66)
    at irma.ejb.serviceSessionManager.ServiceSessionManagerBean.getService(ServiceSessionManagerBean.java:67)
    at irma.ejb.serviceSessionManager.ServiceSessionManager_b1engw_EOImpl.getService

  • "domain was null"; rmicontext=false; JTA UserTransaction;EJB Transaction

    Hi folks!
    I´m doing a test with EJB´s and JTA transactions.
    The goal of the test is to verify if the OC4J will recognize a JTA User Transaction opened by a client just before an EJB method invocation and use it inside the EJB method, instead of opening a new transaction.
    So, I have an EJB with conteiner managed transaction feature "Required".
    And I have a client of this EJB, that opens a JTA UserTransaction and performs some updates and calls the EJB.
    After the EJB call, I throwed a RuntimeException. The proposal of throwing this exception is to force the rollback of all the transaction ( the updates made by the client and the updates made by the ejb must not be commited ).
    My method seems like this ( actually it´s a little bit more structured, but for understading purporses, i put it all in one method only here ):
    <pre>
    public void testTransaction () {
    boolean commit = false;
    javax.transaction.UserTransaction ut = null;
    try {
    // getting the JTA Transaction
    javax.naming.Context initCtx = new javax.naming.InitialContext();
    ut = (javax.transaction.UserTransaction) initCtx.lookup("java:comp/UserTransaction");
    ut.begin();
    try{
    //issue the update
    Connection conn = null;
    try {
    Context ic = new InitialContext();
         DataSource ds = (DataSource) ic.lookup("jdbc/JTADS");
         conn = ds.getConnection();
         PreparedStatement stmt = conn.prepareStatement("UPDATE dont_drop_this_table set field2 =? where field1 = ?");
         stmt.setString(1, "First Record");
         stmt.setInt(2, 1);
         stmt.executeUpdate();
    } finally {
    if (conn != null) conn.close();
    //issue another update via EJB
    Hashtable env = new Hashtable();
    String initialContextFactory = "com.evermind.server.rmi.RMIInitialContextFactory";
    String securityPrincipal = "jazn.com/admin";//admin
    String securityCredentials = "welcome";//admin
    String providerUrl = "ormi://localhost:23791/jta";
    env.put(Context.INITIAL_CONTEXT_FACTORY, initialContextFactory);
    env.put(Context.SECURITY_PRINCIPAL, securityPrincipal);
    env.put(Context.SECURITY_CREDENTIALS, securityCredentials);
    env.put("dedicated.rmicontext", "false");
    env.put("dedicated.connection", "false");
    env.put(Context.PROVIDER_URL, providerUrl);
    Context ctx = new InitialContext(env);
    Object home = ctx.lookup(jndiName);
    Object o = PortableRemoteObject.narrow(home, Class.forName("mytest.MyEJBHome"))
    Class clazz = o.getClass();
    Method method = clazz.getMethod("create", null);
    MyEJBBean bean = (MyEJBBean) method.invoke(o, null);
    //invoking ejb
    bean.updateTable(2, "Second Record")
    //force an ArrayOutOfBoundsException, in order to test
    //if the EJB container will rollback or commit the ejb transaction.
    int x[] = { 0 };
    x[1] = 1;
    x[2] = 1;
    } catch (Exception e) {
    throw new RuntimeException(e);
    //if there was no exception thrown until here... then commit
    commit = true;
    catch ( Exception e ) {
    throw new RuntimeException (e);
    finally {
    try {
    if ( commit ) ut.commit();
    else ut.rollback();
    } catch ( Exception e ) {
    throw new RuntimeException (e);
    </pre>
    Now my question:
    When I use dedicated.rmicontext = true or dedicated.connection = true, the EJB container commits the transaction, even after the exception thrown. I understand that EJB container open a new transaction, instead of use the existing one ( jta UserTransaction.
    When I use dedicated.rmicontext = false and dedicated.connection = false, the EJB container rollbacks the transaction, as I expected.
    I´ve seen many posts about "domain was null" message after a NullPointerException.
    I did many tests, but no NullPointerException was thrown, even when calling the EJB remotely nor issuing concurrent calls.
    - I need the container rollback the transaction.
    - I found that it only rollbacks when I put dedicated.rmicontext = false and dedicated.connection = false.
    - I found that when dedicated.rmicontext = false and dedicated.connection = false, a NullPointerException may ocurr.
    This "domain was null" problem seems to be an OC4J bug and the rmicontext=true an workaround for this bug, but I can´t use rmicontext=true because it will make the EJB transaction not to be the same JTA UserTransaction opened before the EJB call.
    Is there any other way to make an EJB transaction be the same JTA UserTransaction openned before the EJB call?
    PS: I´m using JDeveloper 10.1.2
    Thanks for any help...

    Can anybody help me?
    I need to know how can I set my EJB to use the same connection opened by a POJO class via JTA. ( Actually I need the EJB and POJO class be in same JTA transaction )
    If I set the dedicated.rmicontext to false, it works but I run to risk of getting a NullPointerException "domain was null".
    I realy need your help!
    Thanks!

  • EJB transaction hanging over VPN connection

    EJB transaction hanging over VPN connection
    I am trying to diagnose a problem that only occurs when I am doing testing from home and connected via VPN to work.
    We are using WL 10.3. Our clusters are setup to communicate via multicast. We have a stateless session bean that uses many different resources (Sybase DB, other EJBs, Sonic JMS). I have a local EJB on my home network that I am testing and it connects with other EJBs and resources on my corporate network. While I don't think it is related to the problem, there is a cluster of the same EJB I am trying to test deployed to my corporate environment. i.e. I am testing ResetService EJB and there is a deployed domain cluster of several ResetService EJBs in the environment I am connecting to. My local server and admin domain are named differently than the one deployed and my local ejb shouldn't try to connect to the cluster in the environment.
    When I make a call into my local ejb everything seems to work as expected until it gets to the commit part of the transaction (after my ejb returns). At this point the executing thread hangs at the following location
    "[STUCK] ExecuteThread: '16' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=2 tid=0x2e8cb400 nid=0x22fc in Object.wait() [0x3031f000]
       java.lang.Thread.State: TIMED_WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            - waiting on <0x091a4b18> (a weblogic.transaction.internal.ServerTransactionImpl)
            at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:2130)
            - locked <0x091a4b18> (a weblogic.transaction.internal.ServerTransactionImpl)
            at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:266)
            at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:233)
            at weblogic.ejb.container.internal.BaseRemoteObject.postInvoke1(BaseRemoteObject.java:621)
            at weblogic.ejb.container.internal.StatelessRemoteObject.postInvoke1(StatelessRemoteObject.java:60)
            at weblogic.ejb.container.internal.BaseRemoteObject.postInvokeTxRetry(BaseRemoteObject.java:441)
            at advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean_shnf9c_EOImpl.resetTradeByRate(ResetTradeServiceBean_shnf9c_EOImpl.java:1921)
            at advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean_shnf9c_EOImpl_WLSkel.invoke(Unknown Source)
            at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)
            at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230)
            at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:477)
            at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
            at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
            at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:473)
            at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)
            at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
            at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)This thread is obviously waiting for a notification from some other thread but it is unclear what exactly it is waiting for. This only seems to happen when I am connected via VPN because when I try this same setup connected directly to my corporate network at work it works fine.
    I connected w/ debugger and tried to dig. Some interesting observations I see are.
    1) The ServerTransactionImpl object that is hanging has a 'preferredHost' of a different machine on my corporate network. It is an EJB that my service got some information from but it wasn't involved in any create, update, or delete aspects of the tran so in theory it shouldn't be part of it. Does anyone know what exactly this peferredHost attribute is signifying? I also see this same remote ejb server reference defined in a ServerCoordinatorDescriptor variable.
    2) I also sometimes see other XA resources (JMS) with this ServerTransactionImpl that point to references of resources that live on other machines on my corporate network (not my local ejb). This doesn't always seem to be the case though.
    VPN will definetly block multicast packets from the corporate env back to my machine. I don't think it works from my machine to the corporate env machines either.
    I also have two IPs when connected over VPN. One for my local home network and one given to me by my VPN client. I have setup my local WL server to listen on the VPN client provided IP which the corporate machines should be able to resolve and send TCP message over.
    This definetly seems to be transaction related because when I remove the tran support from my ejb things work as expected. The problem is I need to test within the transaction just like it runs in a deployed environment so this isn't really a fix.
    My theory: My local test WL EJB is waiting for a communication from some other server before it can commit the tran. This communication is blocked due to my VPN connection. I just don't know what exactly it is trying to communicate and how to resolve if that is in fact the problem. I thought about looking into unicast rather than multicast for cluster communication but in my mind that doesn't come into play here because I am not deploying a local cluster for my EJB and I thought multicast was just used for inter-cluster communication.
    I also saw some docs talking about resources need to be uniquely named when inter-domain communication is performed (http://docs.oracle.com/cd/E13222_01/wls/docs81/ConsoleHelp/jta.html#1120356).
    Anyone have any thoughts on what might be going on?
    Here is some log output from my local WL instance:
    Servers in this output--
    My test Server - AdminServer+10.125.105.14:7001+LJDomain+t3
    Server in env I read data from during ejb method call - TradeAccessTS_lkcma00061-1+171.149.24.240:17501+TradeSupportApplication2+t3
    Server in env I read data from during ejb method call - MesaService_lkcma00065-1+171.149.24.244:17501+MESAApplication1+t3
    Server in env I read data from during ejb method call - DataAccess_lkcma00055-0+171.149.24.234:17500+AdvantageApplication1+t3
    Server in env I read data from during ejb method call - DataAccess_lkcma00053-6+171.149.24.232:17506+AdvantageApplication1+t3
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606895> <BEA-000000> <BEA1-0005C168CCCC337F43A8: [EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]: ServerTransactionImpl.commit()>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606895> <BEA-000000> <BEA1-0005C168CCCC337F43A8: [EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]: TX[BEA1-0005C168CCCC337F43A8] active-->pre_preparing>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606896> <BEA-000000> <SC[LJDomain+AdminServer] active-->pre-preparing>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606896> <BEA-000000> <BEA1-0005C168CCCC337F43A8: [EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]: before completion iteration #0>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606896> <BEA-000000> <BEA1-0005C168CCCC337F43A8: [EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]: Synchronization[weblogic.ejb.container.internal.TxManager$TxListener@11b0cf9].beforeCompletion()>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606897> <BEA-000000> <BEA1-0005C168CCCC337F43A8: [EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]: Synchronization[weblogic.ejb.container.internal.TxManager$TxListener@11b0cf9].beforeCompletion() END>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606898> <BEA-000000> <SC[LJDomain+AdminServer] pre-preparing-->pre-prepared>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606898> <BEA-000000> <SC[TradeSupportApplication2+TradeAccessTS_lkcma00061-1] active-->pre-preparing>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606898> <BEA-000000> <BEA1-0005C168CCCC337F43A8: [EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]: delist weblogic.jdbc.wrapper.JTSXAResourceImpl, TMSUSPEND, beforeState=new, startThread=null>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606898> <BEA-000000> <BEA1-0005C168CCCC337F43A8: [EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]: delist weblogic.jdbc.wrapper.JTSXAResourceImpl, afterStatenew>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606899> <BEA-000000> <BEA1-0005C168CCCC337F43A8: [EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]: sc(TradeAccessTS_lkcma00061-1+171.149.24.240:17501+TradeSupportApplication2+t3+).startPrePrepareAndChain>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606900> <BEA-000000> <SC[TradeSupportApplication2+TradeAccessTS_lkcma00061-1] pre-preparing-->pre-preparing>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606902> <BEA-000000> <BEA1-0005C168CCCC337F43A8: [EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]: delist weblogic.jdbc.wrapper.JTSXAResourceImpl, TMSUSPEND, beforeState=new, startThread=null>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606903> <BEA-000000> <BEA1-0005C168CCCC337F43A8: [EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]: delist weblogic.jdbc.wrapper.JTSXAResourceImpl, afterStatenew>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTANaming> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606903> <BEA-000000> <SecureAction.runAction Use Subject= <anonymous>for action:sc.startPrePrepareAndChain to t3://171.149.24.240:17501>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278606903> <BEA-000000> <PropagationContext: Peer=null, Version=4>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278606904> <BEA-000000> < +++ otherPeerInfo.getMajor() :: 10>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278606904> <BEA-000000> < +++ otherPeerInfo.getMinor() :: 3>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278606904> <BEA-000000> < +++ otherPeerInfo.getServicePack() :: 1>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278606905> <BEA-000000> < +++ otherPeerInfo.getRollingPatch() :: 0>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278606905> <BEA-000000> < +++ otherPeerInfo.hasTemporaryPatch() :: false>
    ####<Mar 20, 2012 4:23:26 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0005C168CCCC337F43A8> <> <1332278606905> <BEA-000000> <BEA1-0005C168CCCC337F43A8: [EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]: waitForPrePrepareAcks AdminServer+10.125.105.14:7001+LJDomain+t3+=>pre-prepared TradeAccessTS_lkcma00061-1+171.149.24.240:17501+TradeSupportApplication2+t3+=>pre-preparing MesaService_lkcma00065-1+171.149.24.244:17501+MESAApplication1+t3+=>active DataAccess_lkcma00055-0+171.149.24.234:17500+AdvantageApplication1+t3+=>active DataAccess_lkcma00053-6+171.149.24.232:17506+AdvantageApplication1+t3+=>active>
    $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
    Then eventually I get timeout errors like below in log
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789379> <BEA-000000> < +++ otherPeerInfo.getMajor() :: 10>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789380> <BEA-000000> < +++ otherPeerInfo.getMinor() :: 3>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789380> <BEA-000000> < +++ otherPeerInfo.getServicePack() :: 1>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789381> <BEA-000000> < +++ otherPeerInfo.getRollingPatch() :: 0>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789382> <BEA-000000> < +++ otherPeerInfo.hasTemporaryPatch() :: false>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789382> <BEA-000000> < +++ Using new Method for reading rollback reason....>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTANaming> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789383> <BEA-000000> <RMI call coming from = TradeSupportApplication2>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTANaming> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789384> <BEA-000000> <SecureAction.stranger Subject used on received call: <anonymous> for action: startRollback AUTHENTICATION UNDETERMINABLE use SecurityInteropMode>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789385> <BEA-000000> <PropagationContext.getTransaction: tx=null>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789385> <BEA-000000> <PropagationContext.getTransaction: xid=BEA1-0005C168CCCC337F43A8, isCoordinator=true, infectCoordinatorFirstTime=false, txProps={weblogic.transaction.name=[EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)], weblogic.jdbc=t3://171.149.24.240:17501}>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789391> <BEA-000000> < +++ looking up class : weblogic.transaction.internal.TimedOutException :: in classloader : java.net.URLClassLoader@15e92d7>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789397> <BEA-000000> < +++ looking up class : weblogic.transaction.TimedOutException :: in classloader : java.net.URLClassLoader@15e92d7>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789398> <BEA-000000> < +++ looking up class : java.lang.Exception :: in classloader : java.net.URLClassLoader@15e92d7>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789398> <BEA-000000> < +++ looking up class : java.lang.Throwable :: in classloader : java.net.URLClassLoader@15e92d7>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789402> <BEA-000000> < +++ looking up class : [Ljava.lang.StackTraceElement; ::  in classloader : java.net.URLClassLoader@15e92d7>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789403> <BEA-000000> < +++ looking up class : java.lang.StackTraceElement :: in classloader : java.net.URLClassLoader@15e92d7>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTAPropagate> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789404> <BEA-000000> < +++ converted bytes to rollback reason : weblogic.transaction.internal.TimedOutException: Timed out tx=BEA1-0005C168CCCC337F43A8 after 30000 seconds>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789404> <BEA-000000> <Name=[EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)],Xid=BEA1-0005C168CCCC337F43A8(21880283),Status=Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException: Timed out tx=BEA1-0005C168CCCC337F43A8 after 30000 seconds],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=502,seconds left=29497,activeThread=Thread[[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=new,assigned=none),xar=null,re-Registered = false),SCInfo[LJDomain+AdminServer]=(state=pre-prepared),SCInfo[TradeSupportApplication2+TradeAccessTS_lkcma00061-1]=(state=pre-preparing),SCInfo[MESAApplication1+MesaService_lkcma00065-1]=(state=active),SCInfo[AdvantageApplication1+DataAccess_lkcma00055-0]=(state=active),SCInfo[AdvantageApplication1+DataAccess_lkcma00053-6]=(state=active),properties=({weblogic.transaction.name=[EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)], weblogic.jdbc=t3://171.149.24.240:17501}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=AdminServer+10.125.105.14:7001+LJDomain+t3+, XAResources={LJDomain.AdminServer.JMSXASessionPool.advantage.jms.queue.sonicConnectionFactory, LJDomain.AdminServer.JMSXASessionPool.advantage.jms.topic.sonicConnectionFactory, WLStore_LJDomain__WLS_AdminServer, WSATGatewayRM_AdminServer_LJDomain},NonXAResources={})],CoordinatorURL=AdminServer+10.125.105.14:7001+LJDomain+t3+) wakeUpAfterSeconds(60)>
    ####<Mar 20, 2012 4:26:29 PM CDT> <Debug> <JTA2PC> <F68B599F56D71> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1332278789406> <BEA-000000> <BEA1-0005C168CCCC337F43A8: [EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]: setProperty: weblogic.transaction.name=[EJB advantage.tradesupport.rates.resets.ejb.ResetTradeServiceBean.resetTradeByRate(java.lang.Long,java.util.Set,java.lang.String,java.lang.String,boolean,advantage.common.service.context.ServiceContext)]>

    Hello asirigaya,
    MSDTC configure does not belong to this forum, this forum topic is "Discuss client application development using Windows Forms controls and features."
    I didn't see MSDN has this kind of forum so I will help you move this case to "Where is the forum for"
    Regards,
    Barry Wang
    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click
    HERE to participate the survey.

  • Transaction Rollback Issue in SOA Suite

    Hi All,
    We have been facing the transaction rollback issue very frequently and looking for a concrete solution on this. We have a Asynchronous BPEL process which calls a webservice in a loop of say 20 iteration. In the loop sometimes we face this transaction rollback issue and apparently the CatchAll block doesn't capture this.
    In many blogs and oracle metalink we have seen few settings for this and made as per below :
    1. JTA Transaction timeout increase : we have it 10000 sec.
    2. The Data Source settings : 2.1 : XA transaction timeout check-box selected
    2.2 : The Initial Capacity : 10, Maximum Capacity : 200 and Capacity Increment = 5
    3. soa-infra -> EJBs -> set the transaction timeout to 1200 for many of the recommended BPELs
    4. DISTRIBUTED_LOCK_TIMEOUT = 120 sec.
    In short, all the recommended settings are in place. But still, we are facing this issue. Does anyone know if anything is missing in the setting ? Or any other solution to the issue?
    Any help is truly appreciated.
    Thanks,
    Ashwini

    I think, even if you change the setting you may not get rid of this problem permanently. Try to avoid call to the webservice in a loop and look for any other alternate solution like JMS (thread should not block for the response of the webservice).

  • ORABPEL-08033: EJB Transaction Error

    Hi
    I have a usecase in which procA(sync Service) calling procB (Async Service) and on completion of execution, ProcB gives a non blocking invoke back to procA. Condition: The either of one should be in running state always.
    However there are fault situation in ProcB hence to not to break the sequence we have put a catchAll block which handles/logs and then gives the non blocking invoke back to procA.
    But when ProcB fails somewhere because of some other partner links, it is safely going into catchAll and handling it well and when it tries to do a non blocking invoke it is resulting in following:
    ORABPEL-08033
    EJB Transaction Error.
    EJB exception happened while invoking the partner. Please verify partner service.
    Can somebody give me some leads in this?
    TIA
    regards
    Joy

    I have setup catch statements, both an catch all in the outermost scope and a catch for remote fault at the scope surrounding the call to the AQ. But that's not the issue. The problem is that BPEL don't get the error. The error stay's at the adapter and the BPEL don't come to a failed state.

  • Missing cleanup() after second (local) transaction rollback

              I wrote a simple dummy ressource adapter with local and XA transaction support and
              discovered some problems when using this adapter within an stateless session bean
              that calls setRollbackOnly().
              If I configure the resource adapter for XATransaction support, everything runs fine:
              WebLogic (or its ConnectionManager) detects the transaction rollback calls my cleanup()
              method and delists the connection from the list of busy connections (so I can do
              my rollback test with this connection a often as I want).
              If I configure my resource adapter for LocalTransaction support, the connection also
              is delisted from the list of busy connections (my cleanup method also is called)
              but after a second rollback test the connection remains in the busy connection list
              (and the cleanup call is missing). So calling the rollback test a third time brings
              a ResourceAllocationException.
              I am wondering whether the "mysterious" java.lang.IllegalStateException: Cannot delist
              resource, transaction has been rolled back
              that comes within my server log has something to do with my problem.
              Attched is my server log that reflects the situation.
              Thanks for any hint,
              juergen
              [connectorlog.txt]
              

    Hi Neelam,
    I am sure what exactly your application needs for single-threaded process.
    If you have some thread context in a given thread that you need for correctly handle all message, then you may try to set max-free-pool-size to 1 on the MDB to force single threaded.
    You can find more information in MDB tuning doc at http://download.oracle.com/docs/cd/E17904_01/web.1111/e13814/mdbtuning.htm#PERFM271
    If all you need is to sequentially handle all messages and it does not matter if the processing is done in a particular thread, you could use a JMS feature called Unit-of-order (UOO) together with MDBs. JMS UOO gives you the capability of making sure all messages in one UOO group are processed sequentially and in the order that them are produced, even when there are multiple consumers or redelivery of messages due to fialures. Messages in different UOO groups can be processed in parallel.
    For more information about UOO can be found at http://download.oracle.com/docs/cd/E17904_01/web.1111/e13727/uoo.htm#JMSPG389
    The following link discusses how to process messages in order with MDBs. Re: Transaction-Rollback on foreign jms queue usin Singletonservice in weblogic
    Hope these links help you find the right solution for your application.
    Dongbo

  • Reg MDB transaction rollback

    i have an MDB deployed on weblogic 8.1 sp6 server. My confusion here is how the MDB handles transaction rollbacks. E.g suppose if the MDB is designed to do the below action.
    1) read an xml message from a jms queue
    2) insert some database records
    3) generate some xml message, post it to some other jms queue
    suppose if step 1 and 2 is completed, and its on step 3, at this point weblogic server shutdowns suddenly, once i restart the server, it reads the xml message again from the jms queue, but this time it errors out, because it finds the data already entered in step 2.
    My question is when the weblogic server shut down while the mdb was at step 3, why didnt it removed all the db entries it made in step 2. This behaviour apears to me as partial rollback. I have given the mdb descriptor below.
    <ejb-jar>
      <enterprise-beans>
        <message-driven>
          <ejb-name>CSS_Response</ejb-name>
          <ejb-class>com.bt.neo.core.utility.appcontroller.transport.mdb.JmsMessageReceiver</ejb-class>
          <transaction-type>Container</transaction-type>
          <acknowledge-mode>auto-acknowledge</acknowledge-mode>
          <message-driven-destination>
            <destination-type>javax.jms.Queue</destination-type>
          </message-driven-destination>
          <env-entry>
            <env-entry-name>ejb/BeanFactoryPath</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value>core-css-response-inbound.xml</env-entry-value>
          </env-entry>
          <env-entry>
            <env-entry-name>ProcessorBeanName</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value>transportAdaptor</env-entry-value>
          </env-entry>
          <resource-ref>
            <res-ref-name>jms/faultTo</res-ref-name>
            <res-type>javax.jms.Destination</res-type>
            <res-auth>Container</res-auth>
          </resource-ref>
        </message-driven>
      </enterprise-beans>
      <assembly-descriptor>
        <container-transaction>
          <method>
            <ejb-name>CSS_Response</ejb-name>
            <method-name>onMessage</method-name>
            <method-params>
              <method-param>javax.jms.Message</method-param>
            </method-params>
          </method>
          <trans-attribute>Required</trans-attribute>
        </container-transaction>
      </assembly-descriptor>
    </ejb-jar>Please clear my doubt.
    Edited by: Deepak Dev on 19-Dec-2011 11:01

    General information on message-driven beans can be found here: http://docs.oracle.com/cd/E12840_01/wls/docs103/ejb/message_beans.html
    To transaction configuration is discussed here: http://docs.oracle.com/cd/E12840_01/wls/docs103/ejb/message_beans.html#wp1162058
    Looks like you have to set the transaction-type to Container and the trans-attribute to required. Also see the note:
    - However, if you make this configuration error, the MDB will not run transactionally—if a failure occurs mid-transaction, updates that occurred prior to the failure will not be rolled back.

  • Pls help:  Transaction rollback

    Hi
    We are facing an problem in WLS10. Although I have configured the JTA TimeoutSeconds to 1800 sec, I always hit transaction rollback problem when 30 sec passed. Appreciate your help on this problem.
    DataSource Configuration:
    <jdbc-driver-params>
    <driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
    </jdbc-driver-params>
    <jdbc-connection-pool-params>
    <max-capacity>50</max-capacity>
    <test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
    </jdbc-connection-pool-params>
    <jdbc-data-source-params>
    <jndi-name>jdbc/rms/ctleave</jndi-name>
    <jndi-name></jndi-name>
    <global-transactions-protocol>TwoPhaseCommit</global-transactions-protocol>
    </jdbc-data-source-params>
    JTA configuration:
    -r-- AbandonTimeoutSeconds 86400
    -r-- BeforeCompletionIterationLimit 10
    -r-- CheckpointIntervalSeconds 300
    -r-- ForgetHeuristics true
    -r-- MaxResourceRequestsOnServer 50
    -r-- MaxResourceUnavailableMillis 1800000
    -r-- MaxTransactions 10000
    -r-- MaxUniqueNameStatistics 1000
    -r-- MaxXACallMillis 120000
    -r-- Name LEAVE2FE2
    -r-- Notes null
    -r-- SecurityInteropMode default
    -r-- SerializeEnlistmentsGCIntervalMillis 30000
    -r-- TimeoutSeconds 1800
    -r-- Type JTA
    -r-- UnregisterResourceGracePeriod 30
    -r-x freezeCurrentValue Void : String(attributeName)
    -r-x isSet Boolean : String(propertyName)
    -r-x unSet Void : String(propertyName)
    Exception log:
    Exception Occured, Failure creating new instance of RowMapper, org.apache.beehive.controls.api.ControlException: RowToObjectMapper: SQLEx
    ception: Unexpected exception while enlisting XAConnection java.sql.SQLException: Transaction rolled back: Transaction timed out after 30 seconds
    BEA1-00A6A99F8ED0E04484B3
    at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1419)
    at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1331)
    at weblogic.jdbc.wrapper.JTAConnection.getXAConn(JTAConnection.java:189)
    at weblogic.jdbc.wrapper.JTAConnection.checkConnection(JTAConnection.java:64)
    at weblogic.jdbc.wrapper.ResultSetMetaData.preInvocationHandler(ResultSetMetaData.java:37)
    at weblogic.jdbc.wrapper.ResultSetMetaData_oracle_jdbc_driver_OracleResultSetMetaData.getColumnCount(Unknown Source)
    at org.apache.beehive.controls.system.jdbc.RowToObjectMapper.<init>(RowToObjectMapper.java:63)
    at sun.reflect.GeneratedConstructorAccessor141.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
    at org.apache.beehive.controls.system.jdbc.RowMapperFactory.getMapper(RowMapperFactory.java:160)
    at org.apache.beehive.controls.system.jdbc.RowMapperFactory.getRowMapper(RowMapperFactory.java:85)
    at org.apache.beehive.controls.system.jdbc.DefaultObjectResultSetMapper.arrayFromResultSet(DefaultObjectResultSetMapper.java:93)
    at org.apache.beehive.controls.system.jdbc.DefaultObjectResultSetMapper.mapToResultType(DefaultObjectResultSetMapper.java:61)
    at org.apache.beehive.controls.system.jdbc.JdbcControlImpl.execPreparedStatement(JdbcControlImpl.java:370)
    at org.apache.beehive.controls.system.jdbc.JdbcControlImpl.invoke(JdbcControlImpl.java:228)
    ...

    Hi. Can you turn on JTA logging? The output will show each step in the
    transaction. This should be in the transaction newsgroup.
    Joe
    Shen XiaoChun wrote:
    Hi
    We are facing an problem in WLS10. Although I have configured the JTA TimeoutSeconds to 1800 sec, I always hit transaction rollback problem when 30 sec passed. Appreciate your help on this problem.
    DataSource Configuration:
    <jdbc-driver-params>
    <driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
    </jdbc-driver-params>
    <jdbc-connection-pool-params>
    <max-capacity>50</max-capacity>
    <test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
    </jdbc-connection-pool-params>
    <jdbc-data-source-params>
    <jndi-name>jdbc/rms/ctleave</jndi-name>
    <jndi-name></jndi-name>
    <global-transactions-protocol>TwoPhaseCommit</global-transactions-protocol>
    </jdbc-data-source-params>
    JTA configuration:
    -r-- AbandonTimeoutSeconds 86400
    -r-- BeforeCompletionIterationLimit 10
    -r-- CheckpointIntervalSeconds 300
    -r-- ForgetHeuristics true
    -r-- MaxResourceRequestsOnServer 50
    -r-- MaxResourceUnavailableMillis 1800000
    -r-- MaxTransactions 10000
    -r-- MaxUniqueNameStatistics 1000
    -r-- MaxXACallMillis 120000
    -r-- Name LEAVE2FE2
    -r-- Notes null
    -r-- SecurityInteropMode default
    -r-- SerializeEnlistmentsGCIntervalMillis 30000
    -r-- TimeoutSeconds 1800
    -r-- Type JTA
    -r-- UnregisterResourceGracePeriod 30
    -r-x freezeCurrentValue Void : String(attributeName)
    -r-x isSet Boolean : String(propertyName)
    -r-x unSet Void : String(propertyName)
    Exception log:
    Exception Occured, Failure creating new instance of RowMapper, org.apache.beehive.controls.api.ControlException: RowToObjectMapper: SQLEx
    ception: Unexpected exception while enlisting XAConnection java.sql.SQLException: Transaction rolled back: Transaction timed out after 30 seconds
    BEA1-00A6A99F8ED0E04484B3
    at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1419)
    at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1331)
    at weblogic.jdbc.wrapper.JTAConnection.getXAConn(JTAConnection.java:189)
    at weblogic.jdbc.wrapper.JTAConnection.checkConnection(JTAConnection.java:64)
    at weblogic.jdbc.wrapper.ResultSetMetaData.preInvocationHandler(ResultSetMetaData.java:37)
    at weblogic.jdbc.wrapper.ResultSetMetaData_oracle_jdbc_driver_OracleResultSetMetaData.getColumnCount(Unknown Source)
    at org.apache.beehive.controls.system.jdbc.RowToObjectMapper.<init>(RowToObjectMapper.java:63)
    at sun.reflect.GeneratedConstructorAccessor141.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
    at org.apache.beehive.controls.system.jdbc.RowMapperFactory.getMapper(RowMapperFactory.java:160)
    at org.apache.beehive.controls.system.jdbc.RowMapperFactory.getRowMapper(RowMapperFactory.java:85)
    at org.apache.beehive.controls.system.jdbc.DefaultObjectResultSetMapper.arrayFromResultSet(DefaultObjectResultSetMapper.java:93)
    at org.apache.beehive.controls.system.jdbc.DefaultObjectResultSetMapper.mapToResultType(DefaultObjectResultSetMapper.java:61)
    at org.apache.beehive.controls.system.jdbc.JdbcControlImpl.execPreparedStatement(JdbcControlImpl.java:370)
    at org.apache.beehive.controls.system.jdbc.JdbcControlImpl.invoke(JdbcControlImpl.java:228)

  • Problem with JDBC CONNX (make Rollback)

    When we work with tables in BD since Oracle ADF through this JDBC ConnX operate correctly, except when done in a transaction rollback, which produces the following error performance: "Statement not active."
    To determinate where the error occurred, we have made the following evidence:
    - 1st Test (ADF-BC):
    We create a project a ADF-BC with a single entity and a single view object based on that entity.
    We introduce the View object in an Application Module.
    We execute test Application Module, we have modifying a field of view of a row and then we execute Rollback.
    In this first case, It produce an exception: "Statement not active."
    It occurs the same exception when not change anything, and we do Rollback.
    - 2nd Test (with Java J2EE): You make a Java class that does all the above, but with our Java code:
    Open a connection with the BD Oracle through ConnX.
    We changed the same field in the same row of the same table in the 1st Test, and then we do the Rollback.
    In this second case, the RollBack has functioning properly.
    Close the connection.
    The conclusion of the evidence, is that when we do the 1st Test the RollBack, this Statement is not Active between ADF-BC and JDBC ConnX, but we unknown by that this staments has been closed, and why the project ADF-BC need it.
    We have actived to the project ADF-BC the bigger log that we know: Project Properties> Run-Debug> Edit> Options Java-Djbo.debugoutput = console. And we not finish to detect where the error occurs.
    We need to see the code that generates ADF-BC for this test and thus be able to trace what is running ADF-BC to the lowest level, to identify the problem and to execute a RollBack correctly.
    This is the error Trace:
    [350] EntityCache close prepared statement
    [351] TcomcestapruebaView notify ROLLBACK ...
    [352] Clearing VO cache for TcomcestapruebaView
    [353] Clear QueryCollection in cache for VO TcomcestapruebaView
    [354] Clearing EO cache for es.ramondin.model.views.Tcomcestaprueba
    [355] Clearing VO cache for TcomcestapruebaView
    [356] Clear QueryCollection in cache for VO TcomcestapruebaView
    [357] Column count: 19
    [358] ViewObject: TcomcestapruebaView Reusing defined prepared Statement
    [359] Bind params for ViewObject: TcomcestapruebaView
    [360] ViewObject: TcomcestapruebaView close single-use prepared statements
    [361] QueryCollection.executeQuery failed...
    [362] java.sql.SQLException: STATEMENT NOT ACTIVE
         at com.Connx.jdbc.TCJdbc.TCJdbcStatement.checkContext(TCJdbcStatement.java:1038)
         at com.Connx.jdbc.TCJdbc.TCJdbcStatement.statementCmd(TCJdbcStatement.java:674)
         at com.Connx.jdbc.TCJdbc.TCJdbcPreparedStatement.executeQuery(TCJdbcPreparedStatement.java:78)
         at oracle.jbo.server.QueryCollection.buildResultSet(QueryCollection.java:857)
         at oracle.jbo.server.QueryCollection.executeQuery(QueryCollection.java:666)
         at oracle.jbo.server.ViewObjectImpl.executeQueryForCollection(ViewObjectImpl.java:3655)
         at oracle.jbo.server.ViewRowSetImpl.execute(ViewRowSetImpl.java:742)
         at oracle.jbo.server.ViewRowSetImpl.execute(ViewRowSetImpl.java:687)
         at oracle.jbo.server.ViewRowSetIteratorImpl.ensureRefreshed(ViewRowSetIteratorImpl.java:2657)
         at oracle.jbo.server.ViewRowSetIteratorImpl.ensureRefreshed(ViewRowSetIteratorImpl.java:2634)
         at oracle.jbo.server.ViewRowSetIteratorImpl.first(ViewRowSetIteratorImpl.java:1474)
         at oracle.jbo.server.ViewRowSetImpl.first(ViewRowSetImpl.java:2827)
         at oracle.jbo.server.ViewObjectImpl.first(ViewObjectImpl.java:5724)
         at oracle.jbo.jbotester.ResultWindow.refreshForm(ResultWindow.java:324)
         at oracle.jbo.jbotester.ResultWindow.refreshAll(ResultWindow.java:282)
         at oracle.jbo.jbotester.MainFrame$RollbackAction.doAction(MainFrame.java:903)
         at oracle.jbo.jbotester.AbstractJboAction.actionPerformed(AbstractJboAction.java:81)
         at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
         at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
         at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
         at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
         at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234)
         at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
         at java.awt.Component.processMouseEvent(Component.java:5488)
         at javax.swing.JComponent.processMouseEvent(JComponent.java:3126)
         at java.awt.Component.processEvent(Component.java:5253)
         at java.awt.Container.processEvent(Container.java:1966)
         at java.awt.Component.dispatchEventImpl(Component.java:3955)
         at java.awt.Container.dispatchEventImpl(Container.java:2024)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
         at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
         at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
         at java.awt.Container.dispatchEventImpl(Container.java:2010)
         at java.awt.Window.dispatchEventImpl(Window.java:1774)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
    [363] TcomcestapruebaView>#q old SQLStmtBufLen: 800, actual=770, storing=800
    [364] SELECT Tcomcestaprueba.USUARIO, Tcomcestaprueba.FECHAHORA, Tcomcestaprueba.PROCLI, Tcomcestaprueba.ORDCLI, Tcomcestaprueba.REFPED, Tcomcestaprueba.FECPED, Tcomcestaprueba.SELECCION_MATERIAL, Tcomcestaprueba.SELECCION_ANOS, Tcomcestaprueba.SELECCION_DESTINO, Tcomcestaprueba.SELECCION_ESPESOR, Tcomcestaprueba.SELECCION_COLOR_COSTADO, Tcomcestaprueba.SELECCION_MUESTRAS, Tcomcestaprueba.SELECCION_REFCLIENTE, Tcomcestaprueba.SELECCION_COMPLEX, Tcomcestaprueba.METIDO_CLIENTE, Tcomcestaprueba.AGRUPA_LINEAS, Tcomcestaprueba.SELECCIONADO, Tcomcestaprueba.FACTORIA, Tcomcestaprueba.FECREC FROM DBO.TCOMCESTAPEDIDOS Tcomcestaprueba
    [365] ##### QueryCollection.finl oracle.jbo.Key[]
    [366] oracle.jbo.SQLStmtException: JBO-27122: Error SQL durante la preparación de la sentencia. Sentencia: SELECT Tcomcestaprueba.USUARIO, Tcomcestaprueba.FECHAHORA, Tcomcestaprueba.PROCLI, Tcomcestaprueba.ORDCLI, Tcomcestaprueba.REFPED, Tcomcestaprueba.FECPED, Tcomcestaprueba.SELECCION_MATERIAL, Tcomcestaprueba.SELECCION_ANOS, Tcomcestaprueba.SELECCION_DESTINO, Tcomcestaprueba.SELECCION_ESPESOR, Tcomcestaprueba.SELECCION_COLOR_COSTADO, Tcomcestaprueba.SELECCION_MUESTRAS, Tcomcestaprueba.SELECCION_REFCLIENTE, Tcomcestaprueba.SELECCION_COMPLEX, Tcomcestaprueba.METIDO_CLIENTE, Tcomcestaprueba.AGRUPA_LINEAS, Tcomcestaprueba.SELECCIONADO, Tcomcestaprueba.FACTORIA, Tcomcestaprueba.FECREC FROM DBO.TCOMCESTAPEDIDOS Tcomcestaprueba
         at oracle.jbo.server.BaseSQLBuilderImpl.processException(BaseSQLBuilderImpl.java:3383)
         at oracle.jbo.server.QueryCollection.buildResultSet(QueryCollection.java:958)
         at oracle.jbo.server.QueryCollection.executeQuery(QueryCollection.java:666)
         at oracle.jbo.server.ViewObjectImpl.executeQueryForCollection(ViewObjectImpl.java:3655)
         at oracle.jbo.server.ViewRowSetImpl.execute(ViewRowSetImpl.java:742)
         at oracle.jbo.server.ViewRowSetImpl.execute(ViewRowSetImpl.java:687)
         at oracle.jbo.server.ViewRowSetIteratorImpl.ensureRefreshed(ViewRowSetIteratorImpl.java:2657)
         at oracle.jbo.server.ViewRowSetIteratorImpl.ensureRefreshed(ViewRowSetIteratorImpl.java:2634)
         at oracle.jbo.server.ViewRowSetIteratorImpl.first(ViewRowSetIteratorImpl.java:1474)
         at oracle.jbo.server.ViewRowSetImpl.first(ViewRowSetImpl.java:2827)
         at oracle.jbo.server.ViewObjectImpl.first(ViewObjectImpl.java:5724)
         at oracle.jbo.jbotester.ResultWindow.refreshForm(ResultWindow.java:324)
         at oracle.jbo.jbotester.ResultWindow.refreshAll(ResultWindow.java:282)
         at oracle.jbo.jbotester.MainFrame$RollbackAction.doAction(MainFrame.java:903)
         at oracle.jbo.jbotester.AbstractJboAction.actionPerformed(AbstractJboAction.java:81)
         at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
         at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
         at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
         at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
         at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234)
         at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
         at java.awt.Component.processMouseEvent(Component.java:5488)
         at javax.swing.JComponent.processMouseEvent(JComponent.java:3126)
         at java.awt.Component.processEvent(Component.java:5253)
         at java.awt.Container.processEvent(Container.java:1966)
         at java.awt.Component.dispatchEventImpl(Component.java:3955)
         at java.awt.Container.dispatchEventImpl(Container.java:2024)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
         at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
         at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
         at java.awt.Container.dispatchEventImpl(Container.java:2010)
         at java.awt.Window.dispatchEventImpl(Window.java:1774)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
    ## Detail 0 ##
    java.sql.SQLException: STATEMENT NOT ACTIVE
         at com.Connx.jdbc.TCJdbc.TCJdbcStatement.checkContext(TCJdbcStatement.java:1038)
         at com.Connx.jdbc.TCJdbc.TCJdbcStatement.statementCmd(TCJdbcStatement.java:674)
         at com.Connx.jdbc.TCJdbc.TCJdbcPreparedStatement.executeQuery(TCJdbcPreparedStatement.java:78)
         at oracle.jbo.server.QueryCollection.buildResultSet(QueryCollection.java:857)
         at oracle.jbo.server.QueryCollection.executeQuery(QueryCollection.java:666)
         at oracle.jbo.server.ViewObjectImpl.executeQueryForCollection(ViewObjectImpl.java:3655)
         at oracle.jbo.server.ViewRowSetImpl.execute(ViewRowSetImpl.java:742)
         at oracle.jbo.server.ViewRowSetImpl.execute(ViewRowSetImpl.java:687)
         at oracle.jbo.server.ViewRowSetIteratorImpl.ensureRefreshed(ViewRowSetIteratorImpl.java:2657)
         at oracle.jbo.server.ViewRowSetIteratorImpl.ensureRefreshed(ViewRowSetIteratorImpl.java:2634)
         at oracle.jbo.server.ViewRowSetIteratorImpl.first(ViewRowSetIteratorImpl.java:1474)
         at oracle.jbo.server.ViewRowSetImpl.first(ViewRowSetImpl.java:2827)
         at oracle.jbo.server.ViewObjectImpl.first(ViewObjectImpl.java:5724)
         at oracle.jbo.jbotester.ResultWindow.refreshForm(ResultWindow.java:324)
         at oracle.jbo.jbotester.ResultWindow.refreshAll(ResultWindow.java:282)
         at oracle.jbo.jbotester.MainFrame$RollbackAction.doAction(MainFrame.java:903)
         at oracle.jbo.jbotester.AbstractJboAction.actionPerformed(AbstractJboAction.java:81)
         at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
         at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
         at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
         at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
         at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234)
         at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
         at java.awt.Component.processMouseEvent(Component.java:5488)
         at javax.swing.JComponent.processMouseEvent(JComponent.java:3126)
         at java.awt.Component.processEvent(Component.java:5253)
         at java.awt.Container.processEvent(Container.java:1966)
         at java.awt.Component.dispatchEventImpl(Component.java:3955)
         at java.awt.Container.dispatchEventImpl(Container.java:2024)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
         at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
         at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
         at java.awt.Container.dispatchEventImpl(Container.java:2010)
         at java.awt.Window.dispatchEventImpl(Window.java:1774)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

    Hello Frank,
    We use:
    Sql Flavor: SQL92
    Type Map: Java
    We've done the test with DataDirect JDBC for Oracle and it works fine. It seems that the
    error happens in the function "bindParametersForCollection" which calls the
    other two ones you sent us. We think it's in the
    freeStatament call, but we'd like to review it.
    Thanks in advance.
    This is a new trace more complete:
    [292] ViewObjectImpl.afterRollback(8848) TcomcestapedidosView1 notify ROLLBACK ...
    [293] ViewObjectImpl.doClearCache(8827) Clearing VO cache for TcomcestapedidosView1
    [294] ViewObjectImpl.clearQueryCollectionCache(4640) Clear QueryCollection in cache for VO TcomcestapedidosView1
    [295] DBTransactionImpl.clearEntityCacheInternal(3846) Clearing EO cache for model.Tcomcestapedidos
    [296] ViewObjectImpl.doClearCache(8827) Clearing VO cache for TcomcestapedidosView1
    [297] ViewObjectImpl.clearQueryCollectionCache(4640) Clear QueryCollection in cache for VO TcomcestapedidosView1
    [298] QueryCollection.createColumnList(2527) Column count: 19
    [299] ViewObjectImpl.getPreparedStatement(8179) ViewObject: TcomcestapedidosView1 Reusing defined prepared Statement
    [300] ViewObjectImpl.bindParametersForCollection(13751) Bind params for ViewObject: TcomcestapedidosView1
    [301] ViewObjectImpl.freeStatement(8291) ViewObject: TcomcestapedidosView1 close single-use prepared statements
    [302] QueryCollection.buildResultSet(954) QueryCollection.executeQuery failed...
    [303] Diagnostic.printStackTrace(410) java.sql.SQLException: STATEMENT NOT ACTIVE
         at com.Connx.jdbc.TCJdbc.TCJdbcStatement.checkContext(TCJdbcStatement.java:1038)
         at com.Connx.jdbc.TCJdbc.TCJdbcStatement.statementCmd(TCJdbcStatement.java:674)
         at com.Connx.jdbc.TCJdbc.TCJdbcPreparedStatement.executeQuery(TCJdbcPreparedStatement.java:78)
         at oracle.jbo.server.QueryCollection.buildResultSet(QueryCollection.java:857)
         at oracle.jbo.server.QueryCollection.executeQuery(QueryCollection.java:666)
         at oracle.jbo.server.ViewObjectImpl.executeQueryForCollection(ViewObjectImpl.java:3655)

  • What happens to EJB transaction when user stops/reloads JSP?

    My JSP application uses container managed EJBs. Frequently, my stateless
              session beans manipulate entity beans.
              Does anyone have any documentation about whether or not a containter-managed
              EJB transaction will roll-back in the event that a user clicks "Stop" or
              "Reload" while the bean transaction is processing?
              Thanks in advance,
              DBine.
              http://www.flutter.com
              

    Clicking stop has no effect if the request has already left the browser. It
              just prevents the display of the result. There is nothing you can do about
              that.
              A real problem is if they get impatient and click your link or button
              repeatedly and the back end transaction is (for example) putting a charge
              repeatedly on their credit card. Best way to solve that is to id the
              transaction before it happens (build it in as part of the url or action) and
              only process that id once.
              Cameron Purdy
              [email protected]
              http://www.tangosol.com
              Consulting Services Available
              "dbine" <[email protected]> wrote in message
              news:39b6e29b$[email protected]..
              > My JSP application uses container managed EJBs. Frequently, my stateless
              > session beans manipulate entity beans.
              >
              > Does anyone have any documentation about whether or not a
              containter-managed
              > EJB transaction will roll-back in the event that a user clicks "Stop" or
              > "Reload" while the bean transaction is processing?
              >
              > Thanks in advance,
              >
              > DBine.
              > http://www.flutter.com
              >
              >
              >
              

  • BPEL Sensor for BAM report transaction rollback exception, ORABPEL-05002

    HI,
    I meet a question about BPEL sensor to BAM, it often report below error for Transaction rollback exception and timed out. After this error last half an hour, BPEL will thoughout connect database error and out of Memory.
    It is running on BPEL/BAM 10.1.3.5.
    <2010-01-19 17:33:42,595> <INFO> <default.collaxa.cube.sensor> Flushed 2 rows in BAM batch
    <2010-01-19 17:33:42,600> <INFO> <default.collaxa.cube.sensor> Flushed 6 rows in BAM batch
    <2010-01-19 17:33:42,600> <INFO> <default.collaxa.cube.sensor> Flushed 4 rows in BAM batch
    <2010-01-19 17:33:42,603> <ERROR> <default.collaxa.cube.engine.dispatch> <DispatchHelper::handleMessage> failed to handle message
    javax.ejb.EJBException: An exception occurred during transaction completion: ; nested exception is: javax.transaction.RollbackException: Timed out
    javax.transaction.RollbackException: Timed out
         at com.evermind.server.ApplicationServerTransaction.checkForRollbackOnlyWhileInCommit(ApplicationServerTransaction.java:633)
         at com.evermind.server.ApplicationServerTransaction.doCommit(ApplicationServerTransaction.java:273)
         at com.evermind.server.ApplicationServerTransaction.commit(ApplicationServerTransaction.java:162)
         at com.evermind.server.ApplicationServerTransactionManager.commit(ApplicationServerTransactionManager.java:472)
         at com.evermind.server.ejb.EJBTransactionManager.end(EJBTransactionManager.java:132)
         at com.evermind.server.ejb.interceptor.system.TxRequiredInterceptor.invoke(TxRequiredInterceptor.java:57)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:87)
         at CubeDeliveryBean_LocalProxy_4bin6i8.handleInvoke(Unknown Source)
         at com.collaxa.cube.engine.dispatch.message.invoke.InvokeInstanceMessageHandler.handle(InvokeInstanceMessageHandler.java:37)
         at com.collaxa.cube.engine.dispatch.DispatchHelper.handleMessage(DispatchHelper.java:138)
         at com.collaxa.cube.engine.dispatch.BaseScheduledWorker.process(BaseScheduledWorker.java:70)
         at com.collaxa.cube.engine.ejb.impl.WorkerBean.onMessage(WorkerBean.java:86)
         at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.SetContextActionInterceptor.invoke(SetContextActionInterceptor.java:44)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at oracle.j2ee.connector.messageinflow.MessageEndpointImpl.OC4J_invokeMethod(MessageEndpointImpl.java:297)
         at WorkerBean_EndPointProxy_4bin6i8.onMessage(Unknown Source)
         at oracle.j2ee.ra.jms.generic.WorkConsumer.run(WorkConsumer.java:266)
         at oracle.j2ee.connector.work.WorkWrapper.runTargetWork(WorkWrapper.java:242)
         at oracle.j2ee.connector.work.WorkWrapper.doWork(WorkWrapper.java:215)
         at oracle.j2ee.connector.work.WorkWrapper.run(WorkWrapper.java:190)
         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:814)
         at java.lang.Thread.run(Thread.java:595)
    javax.ejb.EJBException: An exception occurred during transaction completion: ; nested exception is: javax.transaction.RollbackException: Timed out
         at com.evermind.server.ejb.EJBUtils.createEJBException(EJBUtils.java:365)
         at com.evermind.server.ejb.EJBTransactionManager.end(EJBTransactionManager.java:139)
         at com.evermind.server.ejb.interceptor.system.TxRequiredInterceptor.invoke(TxRequiredInterceptor.java:57)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:87)
         at CubeDeliveryBean_LocalProxy_4bin6i8.handleInvoke(Unknown Source)
         at com.collaxa.cube.engine.dispatch.message.invoke.InvokeInstanceMessageHandler.handle(InvokeInstanceMessageHandler.java:37)
         at com.collaxa.cube.engine.dispatch.DispatchHelper.handleMessage(DispatchHelper.java:138)
         at com.collaxa.cube.engine.dispatch.BaseScheduledWorker.process(BaseScheduledWorker.java:70)
         at com.collaxa.cube.engine.ejb.impl.WorkerBean.onMessage(WorkerBean.java:86)
         at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.SetContextActionInterceptor.invoke(SetContextActionInterceptor.java:44)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at oracle.j2ee.connector.messageinflow.MessageEndpointImpl.OC4J_invokeMethod(MessageEndpointImpl.java:297)
         at WorkerBean_EndPointProxy_4bin6i8.onMessage(Unknown Source)
         at oracle.j2ee.ra.jms.generic.WorkConsumer.run(WorkConsumer.java:266)
         at oracle.j2ee.connector.work.WorkWrapper.runTargetWork(WorkWrapper.java:242)
         at oracle.j2ee.connector.work.WorkWrapper.doWork(WorkWrapper.java:215)
         at oracle.j2ee.connector.work.WorkWrapper.run(WorkWrapper.java:190)
         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:814)
         at java.lang.Thread.run(Thread.java:595)
    Caused by: javax.transaction.RollbackException: Timed out
         at com.evermind.server.ApplicationServerTransaction.checkForRollbackOnlyWhileInCommit(ApplicationServerTransaction.java:633)
         at com.evermind.server.ApplicationServerTransaction.doCommit(ApplicationServerTransaction.java:273)
         at com.evermind.server.ApplicationServerTransaction.commit(ApplicationServerTransaction.java:162)
         at com.evermind.server.ApplicationServerTransactionManager.commit(ApplicationServerTransactionManager.java:472)
         at com.evermind.server.ejb.EJBTransactionManager.end(EJBTransactionManager.java:132)
         ... 29 more
    <2010-01-19 17:33:42,604> <ERROR> <default.collaxa.cube.engine.dispatch> <BaseScheduledWorker::process> Failed to handle dispatch message ... exception ORABPEL-05002
    Message handle error.
    An exception occurred while attempting to process the message "com.collaxa.cube.engine.dispatch.message.invoke.InvokeInstanceMessage"; the exception is: An exception occurred during transaction completion: ; nested exception is: javax.transaction.RollbackException: Timed out
    ORABPEL-05002
    Message handle error.
    An exception occurred while attempting to process the message "com.collaxa.cube.engine.dispatch.message.invoke.InvokeInstanceMessage"; the exception is: An exception occurred during transaction completion: ; nested exception is: javax.transaction.RollbackException: Timed out
         at com.collaxa.cube.engine.dispatch.DispatchHelper.handleMessage(DispatchHelper.java:171)
         at com.collaxa.cube.engine.dispatch.BaseScheduledWorker.process(BaseScheduledWorker.java:70)
         at com.collaxa.cube.engine.ejb.impl.WorkerBean.onMessage(WorkerBean.java:86)
         at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.SetContextActionInterceptor.invoke(SetContextActionInterceptor.java:44)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at oracle.j2ee.connector.messageinflow.MessageEndpointImpl.OC4J_invokeMethod(MessageEndpointImpl.java:297)
         at WorkerBean_EndPointProxy_4bin6i8.onMessage(Unknown Source)
         at oracle.j2ee.ra.jms.generic.WorkConsumer.run(WorkConsumer.java:266)
         at oracle.j2ee.connector.work.WorkWrapper.runTargetWork(WorkWrapper.java:242)
         at oracle.j2ee.connector.work.WorkWrapper.doWork(WorkWrapper.java:215)
         at oracle.j2ee.connector.work.WorkWrapper.run(WorkWrapper.java:190)
         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:814)
         at java.lang.Thread.run(Thread.java:595)
    <2010-01-19 17:33:42,605> <ERROR> <default.collaxa.cube.engine.dispatch> <DispatchHelper::handleMessage> failed to handle message
    javax.ejb.EJBException: An exception occurred during transaction completion: ; nested exception is: javax.transaction.RollbackException: Timed out
    javax.transaction.RollbackException: Timed out
         at com.evermind.server.ApplicationServerTransaction.checkForRollbackOnlyWhileInCommit(ApplicationServerTransaction.java:633)
         at com.evermind.server.ApplicationServerTransaction.doCommit(ApplicationServerTransaction.java:273)
         at com.evermind.server.ApplicationServerTransaction.commit(ApplicationServerTransaction.java:162)
         at com.evermind.server.ApplicationServerTransactionManager.commit(ApplicationServerTransactionManager.java:472)
         at com.evermind.server.ejb.EJBTransactionManager.end(EJBTransactionManager.java:132)
         at com.evermind.server.ejb.interceptor.system.TxRequiredInterceptor.invoke(TxRequiredInterceptor.java:57)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:87)
         at CubeDeliveryBean_LocalProxy_4bin6i8.handleInvoke(Unknown Source)
         at com.collaxa.cube.engine.dispatch.message.invoke.InvokeInstanceMessageHandler.handle(InvokeInstanceMessageHandler.java:37)
         at com.collaxa.cube.engine.dispatch.DispatchHelper.handleMessage(DispatchHelper.java:138)
         at com.collaxa.cube.engine.dispatch.BaseScheduledWorker.process(BaseScheduledWorker.java:70)
         at com.collaxa.cube.engine.ejb.impl.WorkerBean.onMessage(WorkerBean.java:86)
         at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.SetContextActionInterceptor.invoke(SetContextActionInterceptor.java:44)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at oracle.j2ee.connector.messageinflow.MessageEndpointImpl.OC4J_invokeMethod(MessageEndpointImpl.java:297)
         at WorkerBean_EndPointProxy_4bin6i8.onMessage(Unknown Source)
         at oracle.j2ee.ra.jms.generic.WorkConsumer.run(WorkConsumer.java:266)
         at oracle.j2ee.connector.work.WorkWrapper.runTargetWork(WorkWrapper.java:242)
         at oracle.j2ee.connector.work.WorkWrapper.doWork(WorkWrapper.java:215)
         at oracle.j2ee.connector.work.WorkWrapper.run(WorkWrapper.java:190)
         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:814)
         at java.lang.Thread.run(Thread.java:595)
    javax.ejb.EJBException: An exception occurred during transaction completion: ; nested exception is: javax.transaction.RollbackException: Timed out
         at com.evermind.server.ejb.EJBUtils.createEJBException(EJBUtils.java:365)
         at com.evermind.server.ejb.EJBTransactionManager.end(EJBTransactionManager.java:139)
         at com.evermind.server.ejb.interceptor.system.TxRequiredInterceptor.invoke(TxRequiredInterceptor.java:57)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:87)
         at CubeDeliveryBean_LocalProxy_4bin6i8.handleInvoke(Unknown Source)
         at com.collaxa.cube.engine.dispatch.message.invoke.InvokeInstanceMessageHandler.handle(InvokeInstanceMessageHandler.java:37)
         at com.collaxa.cube.engine.dispatch.DispatchHelper.handleMessage(DispatchHelper.java:138)
         at com.collaxa.cube.engine.dispatch.BaseScheduledWorker.process(BaseScheduledWorker.java:70)
         at com.collaxa.cube.engine.ejb.impl.WorkerBean.onMessage(WorkerBean.java:86)
         at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.SetContextActionInterceptor.invoke(SetContextActionInterceptor.java:44)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at oracle.j2ee.connector.messageinflow.MessageEndpointImpl.OC4J_invokeMethod(MessageEndpointImpl.java:297)
         at WorkerBean_EndPointProxy_4bin6i8.onMessage(Unknown Source)
         at oracle.j2ee.ra.jms.generic.WorkConsumer.run(WorkConsumer.java:266)
         at oracle.j2ee.connector.work.WorkWrapper.runTargetWork(WorkWrapper.java:242)
         at oracle.j2ee.connector.work.WorkWrapper.doWork(WorkWrapper.java:215)
         at oracle.j2ee.connector.work.WorkWrapper.run(WorkWrapper.java:190)
         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:814)
         at java.lang.Thread.run(Thread.java:595)
    Caused by: javax.transaction.RollbackException: Timed out
         at com.evermind.server.ApplicationServerTransaction.checkForRollbackOnlyWhileInCommit(ApplicationServerTransaction.java:633)
         at com.evermind.server.ApplicationServerTransaction.doCommit(ApplicationServerTransaction.java:273)
         at com.evermind.server.ApplicationServerTransaction.commit(ApplicationServerTransaction.java:162)
         at com.evermind.server.ApplicationServerTransactionManager.commit(ApplicationServerTransactionManager.java:472)
         at com.evermind.server.ejb.EJBTransactionManager.end(EJBTransactionManager.java:132)
         ... 29 more
    After half an hour, BPEL will report below error log:
    ORABPEL-04067
    Cannot update invoke message.
    The process domain was unable to update the state of the invocation message "99e5b70b31758b56:3c0225db:126439fa400:48c0". The exception reported is: Io exception: Connection reset
    Please check that the machine hosting the datasource is physically connected to the network. Otherwise, check that the datasource connection parameters (user/password) is currently valid.
    sql statement: UPDATE invoke_message SET state = ? WHERE message_guid = ?
    I am not sure these two error has any relationship.
    But it is an issue that BAM sensor ofter report transaction time out.

    sorry, I forgot the below things which I tried to tune the JMS.
    <property name="retryMaxCount">10</property>
    <property name="retryInterval">60</property>
    <property name="useJCAConnectionPool">true</property>
    <property name="maxSizeJCAConnectionPool">500</property>
    Thanks.

  • Monitor EJB transaction timeout value

    Hi,
    I try to create a test case to monitor transaction timeout and rollback value
    (not 0) from weblogic 6.1 console. By adding the timeout value to the weblogic-ejb-jar.xml
    and rebuild the beanManaged example, I successfully create the scenario by seeing
    the timeout and transaction rollback exception from the server. However, from
    console the timeout value and rollback value of EJB monitoring still show "0"
    not any number I expected. Any bug from Weblogic?
    Thanks, Cathy

    The following configuration seems working:
    version: OC4J (9.0.3.0.0) (build 020927.1699)
    AM deployment:
    - bc4j.xcfg: <jbo.ejb.txntimeout>30000</jbo.ejb.txntimeout>
    - orion-ejb-jar.xml: <session-deployment name="..." timeout="0"/>
    OC4J config:
    - data-source: inactivity-timeout="30000"
    This keeps connection open for more than default 30 mins of inactivity (30000 secs configured).
    Although, oc4j console prints multiple warnings:
    DriverManagerConnectionPoolConnection not closed, check your code!
    Looks like this is not an intended usage - but working.
    Notice that it was a test, not a production environment.
    Also pls see 9033: AM as EJB Session bean: pooled connection lost for new txn
    I would be thankful for any experience in running AM Session EJB w/o timeout.

  • EJB Transaction timeout and Statement Query Timeout

    I am looking for some details on how statement query timeout is set when statement execution is part of the session bean transaction. I have done some test in webshere 6.1. and JBoss 5.0 and not getting the desired behavior. My understanding is following
    - DB is Oracle 11g
    - EJB transaction is set to 5 mins.
    - Query time out setting is set to default vaule (not sure what is the default value)
    - Session bean is updating say customer record using PreparedStatement
    - Prior to calling session bean method I am locking the customer record using external/db tool and holding the lock.
    - Call session bean method. Method waits endlessly for the lock to be acquired. No transaction rollback after 5 mins.
    - After 10 minutes commit the transaction in the external db tool
    - Session bean methods throws transaction rollback.
    My understanding was that query timeout is set based on transaction "time to live". Please share out thoughts.
    Edited by: hdjava on Jun 18, 2010 1:06 PM
    Edited by: hdjava on Jun 18, 2010 1:07 PM

    The following configuration seems working:
    version: OC4J (9.0.3.0.0) (build 020927.1699)
    AM deployment:
    - bc4j.xcfg: <jbo.ejb.txntimeout>30000</jbo.ejb.txntimeout>
    - orion-ejb-jar.xml: <session-deployment name="..." timeout="0"/>
    OC4J config:
    - data-source: inactivity-timeout="30000"
    This keeps connection open for more than default 30 mins of inactivity (30000 secs configured).
    Although, oc4j console prints multiple warnings:
    DriverManagerConnectionPoolConnection not closed, check your code!
    Looks like this is not an intended usage - but working.
    Notice that it was a test, not a production environment.
    Also pls see 9033: AM as EJB Session bean: pooled connection lost for new txn
    I would be thankful for any experience in running AM Session EJB w/o timeout.

Maybe you are looking for

  • IPod mini can't see firewire power adapter after 1.4.1 update

    I updated my mini to the (infamous) 1.4.1 update, and now my firewire connection doesn't appear to work. When plugged into the computer with the firewire cable, mini doesn't appear on desktop or in iTunes, though it will start recharging the battery.

  • [FLEX 3 AIR]

    This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C82210.F130FDC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hola, por favor alguien podria ayudarme, estoy haciendo una pequena =

  • Unicode conversion Issue

    Hi, We are using excel macros to load vendors. VB script in excel will call extenral RFC in SAP to validate and load vendors. SAP being an Unicode system and excel a non unicode system, is giving us issues while loading foreign characters other than

  • Need clarifications regarding APEX_PUBLIC_USER

    Hello all, Apex 3.0 on 10g 'am aware that APEX_PUBLIC_USER is the one used by the apex applications to get the stuff from the database. I have noticed that in v$session there do exist the apex_public_user even if i logout from the apex. In my product

  • IPhoto unexpectedly quit and lost pics

    I had just uploaded about 50 pics over the course of 3 hours, was importing movie to iMovie, iPhoto quit, reopened it and the pics I had uploaded were gone. There's an event where they were but has 0 pictures. What happened and how do I get them back