Transaction Timeout (BPEL v10.1.2.0.0, WebLogic 8.1 sp4)

We are attempting to process a transform on a medium sized xml doc (~4.5 MB). For the test case we are simply reading the the doc using the FileAdapter, performing a transformation, and then writing the result to a file using the FileAdapter once again. The flow works fine for smallish files (under ~4MB), however, when dropping a file greater than that size the flow fails once finished while writing entries to the BPEL audit log with a TransactionTimedOutException (see exception below).
I understand what is happening and why (it certainly takes longer than 2 mins to process the file). I have also done quite a bit of digging around for references to this issue and found several posts regarding bumping the transaction timeout value when running the OC4J container. My problem is that we are not running the OC4J container. I know how to manage the default transaction timeout value for WebLogic but it appears that the BPEL application doesn't seem to be honoring the default transaction timeout on the WL Server. I have come to this conclusion for two reasons: first, the default transaction timeout on the WL Server (before modification) is 30 seconds, not the 120 seconds that this transaction is timing out on. second, changing the transaction timeout value on the WebLogic server has no impact on this issue what so ever. I can set the transaction timeout to any value I like, the process ALWAYS times out after 120 seconds.
Is there another setting on the BPEL server that I may have missed that is overriding the default timeout, i.e. is it possible that when the BPEL server process is starting the transaction it is setting the timeout on the TransactionManager in code prior to starting the transaction?
Any pointers are greatly appreciated.
------------- START STACK TRACE ------------------
<2007-03-15 13:50:24,625> <ERROR> <default.collaxa.cube> <BaseCubeSessionBean::logError> Error while invoking bean "cube delivery": Cannot insert audit trail.
The process domain was unable to insert the current log entries for the instance "10601" to the audit trail table. The exception reported is: The transaction is no longer active - status: 'Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 120 seconds
Name=[EJB com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(java.lang.String,com.oracle.bpel.client.auth.DomainAuth)],Xid=BEA1-0021B65431A170F9CFEF(31469464),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=120,seconds left=60,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread Group for Queue: 'default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@154d033,re-Registered = false),SCInfo[f58_integration+orabpelServer]=(state=active),properties=({weblogic.transaction.name=[EJB com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(java.lang.String,com.oracle.bpel.client.auth.DomainAuth)], weblogic.jdbc=t3://127.0.0.1:9700}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=orabpelServer+127.0.0.1:9700+f58_integration+t3+, XAResources={},NonXAResources={})],CoordinatorURL=orabpelServer+127.0.0.1:9700+f58_integration+t3+)]'. No further JDBC access is allowed within this transaction.
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: INSERT INTO audit_trail( cikey, domain_ref, count_id, block, block_csize, block_usize, log ) VALUES( ?, ?, ?, ?, ?, ?, ? )
<2007-03-15 13:50:24,643> <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: Transaction Rolledback.: weblogic.transaction.internal.TimedOutException: Transaction timed out after 120 seconds
Name=[EJB com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(java.lang.String,com.oracle.bpel.client.auth.DomainAuth)],Xid=BEA1-0021B65431A170F9CFEF(31469464),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=120,seconds left=60,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread Group for Queue: 'default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@154d033,re-Registered = false),SCInfo[f58_integration+orabpelServer]=(state=active),properties=({weblogic.transaction.name=[EJB com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(java.lang.String,com.oracle.bpel.client.auth.DomainAuth)], weblogic.jdbc=t3://127.0.0.1:9700}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=orabpelServer+127.0.0.1:9700+f58_integration+t3+, XAResources={},NonXAResources={})],CoordinatorURL=orabpelServer+127.0.0.1:9700+f58_integration+t3+)
at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(ServerTransactionImpl.java:1614)
at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(ServerTransactionManagerImpl.java:1117)
at weblogic.transaction.internal.TransactionManagerImpl.wakeUp(TransactionManagerImpl.java:1881)
at weblogic.transaction.internal.ServerTransactionManagerImpl.wakeUp(ServerTransactionManagerImpl.java:1034)
at weblogic.transaction.internal.WLSTimer.trigger(WLSTimer.java:31)
at weblogic.time.common.internal.ScheduledTrigger.run(ScheduledTrigger.java:243)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:229)
at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:223)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
; nested exception is: weblogic.transaction.internal.TimedOutException: Transaction timed out after 120 seconds
Name=[EJB com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(java.lang.String,com.oracle.bpel.client.auth.DomainAuth)],Xid=BEA1-0021B65431A170F9CFEF(31469464),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=120,seconds left=60,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread Group for Queue: 'default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@154d033,re-Registered = false),SCInfo[f58_integration+orabpelServer]=(state=active),properties=({weblogic.transaction.name=[EJB com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(java.lang.String,com.oracle.bpel.client.auth.DomainAuth)], weblogic.jdbc=t3://127.0.0.1:9700}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=orabpelServer+127.0.0.1:9700+f58_integration+t3+, XAResources={},NonXAResources={})],CoordinatorURL=orabpelServer+127.0.0.1:9700+f58_integration+t3+)
------------- END STACK TRACE ------------------

Hi
i am facing a similar problem..did u find the solution for this problem?
Please pass the solution/workaround u performed for solving this...
Thanks & Regards
Subramanian

Similar Messages

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

  • Transaction timeout in BPEL for webservice invocation

    [ERROR] [] [oracle.soa.bpel.engine.dispatch] [tid: orabpel.invoke.pool-4.thread-3] [userId: <anonymous>] [ecid: e8538d226bae7c2a:1914e8c0:148c67a5f26:-8000-00000000000031a2,1:27459] [APP: soa-infra] failed to handle message[[
    weblogic.transaction.internal.TimedOutException: Transaction timed out after 299 seconds
    BEA1-166C02569896A59BE380
                    at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(ServerTransactionImpl.java:1788)
                    at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(ServerTransactionManagerImpl.java:1676)
                    at weblogic.transaction.internal.TransactionManagerImpl.wakeUp(TransactionManagerImpl.java:1988)
                    at weblogic.transaction.internal.ServerTransactionManagerImpl.wakeUp(ServerTransactionManagerImpl.java:1586)
                    at weblogic.transaction.internal.WLSTimer.timerExpired(WLSTimer.java:35)
                    at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
                    at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
                    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
                    at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
    Message handle error.
    error while attempting to process the message "com.collaxa.cube.engine.dispatch.message.invoke.InvokeInstanceMessage"; the reported exception is: Transaction Rolledback.: weblogic.transaction.internal.TimedOutException: Transaction timed out after 299 seconds
    BEA1-166C02569896A59BE380
    This is happening when invoking a webservices from BPEL and if it takes more than 5 minutes we are getting above Error
    we have tried out SyncMaxWaitTime Property in BPEL configurations through SOA administration menu of EM. Also tried by increasing JTA timeout seconds in Service--JTA @ weblogic console.
    Any suggestion or pointers..

    Hi,
    Could help set the following...
    The timeouts should be configured based on the below condition
    SyncMaxWaitTime < BPEL EJB's transaction timeout < Global Transaction Timeout
    The values could be: SyncMaxWaitTime (3600) ; BPEL EJB's transaction timeout (3600); Global Transaction Timeout JTA (7200)
    Setting the SyncMaxWaitTime :
    This is the maximum time a synchronous BPEL process waits before it times out to get the response from another BPEL or a web service
    Login to EM console
    Expand SOA and right click on "soa-infra"
    From context menu, select SOA Administration –> BPEL properties
    Click on "More BPEL Configuration properties"
    Enter the appropriate value for the SyncMaxWaitTime
    Setting the global transaction timeout at Weblogic Domain Level:
    This property controls the transaction timeout seconds for active transactions. If the transaction is still in the "active" state after this time, it is automatically rolled back. 
    Log into Oracle Weblogic Administration Console.
    Click Services -> JTA.
    Change the value of Timeout Seconds to the required value (the default is 30)
    Click Save.
    Restart Oracle Weblogic Server.
    Overriding the transaction timeout setting for BPEL EJB's:
    The timeout properties for the EJB's control the particular timeout setting for the SOA application, overriding the global setting specified by the JTA timeout 
    Log into Oracle Weblogic Administration Console.
    Click Deployments.
    Expand soa-infra -> EJBs.
    Click on the configuration tab for the timeout setting for each of EJB’s listed below and the change the time out values as required.
    Following EJBs need to be updated:
    BPELActivityManagerBean  
    BPELDeliveryBean
    BPELDispatcherBean
    BPELEngineBean
    BPELFinderBean
    BPELInstanceManagerBean
    BPELProcessManagerBean
    BPELSensorValuesBean
    BPELServerManagerBean
    Click Save.
    Restart Oracle Weblogic Server.
    I hope you find it useful!
    hugs!

  • Transaction timeout for FTP Put as an attachment

    Hi,
    When I am trying to get a file from E Business Suite(Oracle Apps) and place the same in to FTP Outbound as an attachment, I am getting the below exception. This did not happen in PS2 but it is happening in PS3(11.11.1.4) with the same code, can some please me on this. The file size is around 16MB. I have restriction to increase the transaction timeout value in the through admin server.
    java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: Transaction rolled back: Transaction timed out after 299 seconds BEA1-0672B035E0F02A163299 at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1616) at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1503) at weblogic.jdbc.wrapper.JTAConnection.getXAConn(JTAConnection.java:205) at weblogic.jdbc.wrapper.JTAConnection.checkConnection(JTAConnection.java:74) at weblogic.jdbc.wrapper.JTAConnection.checkConnection(JTAConnection.java:65) at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:94) at weblogic.jdbc.wrapper.Connection.prepareStatement(Connection.java:496) at oracle.integration.platform.xml.XMLDocumentManagerImpl.insertDocument(XMLDocumentManagerImpl.java:648) at oracle.integration.platform.xml.XMLDocumentManagerImpl.insertDocument(XMLDocumentManagerImpl.java:185) at sun.reflect.GeneratedMethodAccessor2001.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy336.insertDocument(Unknown Source) at oracle.integration.platform.instance.store.MessageStore.savePayload(MessageStore.java:248) at oracle.integration.platform.instance.store.MessageStore.savePayloads(MessageStore.java:102) at oracle.integration.platform.instance.InstanceManagerImpl.persistPayloads(InstanceManagerImpl.java:798) at oracle.integration.platform.instance.InstanceManagerImpl.persistReferenceInstanceBean(InstanceManagerImpl.java:1150) at oracle.integration.platform.blocks.adapter.AbstractAdapterBindingComponent.createAndPersistBindingInstance(AbstractAdapterBindingComponent.java:504) at oracle.integration.platform.blocks.adapter.AdapterReference.createAndPersistBindingInstance(AdapterReference.java:357) at oracle.integration.platform.blocks.adapter.AdapterReference.createBindingInstance(AdapterReference.java:331) at oracle.integration.platform.blocks.adapter.AdapterReference.post(AdapterReference.java:253) at oracle.integration.platform.blocks.mesh.AsynchronousMessageHandler.doPost(AsynchronousMessageHandler.java:142) at oracle.integration.platform.blocks.mesh.MessageRouter.post(MessageRouter.java:194) at oracle.integration.platform.blocks.mesh.MeshImpl.post(MeshImpl.java:215) at sun.reflect.GeneratedMethodAccessor3279.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at oracle.integration.platform.metrics.PhaseEventAspect.invoke(PhaseEventAspect.java:71) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy333.post(Unknown Source) at oracle.fabric.CubeServiceEngine.postToMesh(CubeServiceEngine.java:806) at com.collaxa.cube.ws.WSInvocationManager.invoke(WSInvocationManager.java:258) at com.collaxa.cube.engine.ext.common.InvokeHandler.__invoke(InvokeHandler.java:1056) at com.collaxa.cube.engine.ext.common.InvokeHandler.handleNormalInvoke(InvokeHandler.java:583) at com.collaxa.cube.engine.ext.common.InvokeHandler.handle(InvokeHandler.java:130) at com.collaxa.cube.engine.ext.bpel.common.wmp.BPELInvokeWMP.__executeStatements(BPELInvokeWMP.java:74) at com.collaxa.cube.engine.ext.bpel.common.wmp.BaseBPELActivityWMP.perform(BaseBPELActivityWMP.java:158) at com.collaxa.cube.engine.CubeEngine._performActivity(CubeEngine.java:2463) at com.collaxa.cube.engine.CubeEngine.performActivity(CubeEngine.java:2334) at com.collaxa.cube.engine.CubeEngine.handleWorkItem(CubeEngine.java:1115) at com.collaxa.cube.engine.dispatch.message.instance.PerformMessageHandler.handleLocal(PerformMessageHandler.java:73) at com.collaxa.cube.engine.dispatch.DispatchHelper.handleLocalMessage(DispatchHelper.java:220) at com.collaxa.cube.engine.dispatch.DispatchHelper.sendMemory(DispatchHelper.java:328) at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:4350) at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:4281) at com.collaxa.cube.engine.CubeEngine.createAndInvoke(CubeEngine.java:679) at com.collaxa.cube.engine.delivery.DeliveryService.handleInvoke(DeliveryService.java:654) at com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(CubeDeliveryBean.java:293) at sun.reflect.GeneratedMethodAccessor6353.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at com.bea.core.repackaged.springframework.jee.intercept.MethodInvocationInvocationContext.proceed(MethodInvocationInvocationContext.java:104) at oracle.security.jps.ee.ejb.JpsAbsInterceptor$1.run(JpsAbsInterceptor.java:94) at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:313) at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:413) at oracle.security.jps.ee.ejb.JpsAbsInterceptor.runJaasMode(JpsAbsInterceptor.java:81) at oracle.security.jps.ee.ejb.JpsAbsInterceptor.intercept(JpsAbsInterceptor.java:112) at oracle.security.jps.ee.ejb.JpsInterceptor.intercept(JpsInterceptor.java:105) at sun.reflect.GeneratedMethodAccessor1143.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310) at com.bea.core.repackaged.springframework.jee.intercept.JeeInterceptorInterceptor.invoke(JeeInterceptorInterceptor.java:69) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.jee.spi.MethodInvocationVisitorImpl.visit(MethodInvocationVisitorImpl.java:37) at weblogic.ejb.container.injection.EnvironmentInterceptorCallbackImpl.callback(EnvironmentInterceptorCallbackImpl.java:54) at com.bea.core.repackaged.springframework.jee.spi.EnvironmentInterceptor.invoke(EnvironmentInterceptor.java:50) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy316.handleInvoke(Unknown Source) at com.collaxa.cube.engine.ejb.impl.bpel.BPELDeliveryBean_5k948i_ICubeDeliveryLocalBeanImpl.__WL_invoke(Unknown Source) at weblogic.ejb.container.internal.SessionLocalMethodInvoker.invoke(SessionLocalMethodInvoker.java:39) at com.collaxa.cube.engine.ejb.impl.bpel.BPELDeliveryBean_5k948i_ICubeDeliveryLocalBeanImpl.handleInvoke(Unknown Source) at com.collaxa.cube.engine.dispatch.message.invoke.InvokeInstanceMessageHandler.handle(InvokeInstanceMessageHandler.java:35) at com.collaxa.cube.engine.dispatch.DispatchHelper.handleMessage(DispatchHelper.java:140) at com.collaxa.cube.engine.dispatch.BaseDispatchTask.process(BaseDispatchTask.java:88) at com.collaxa.cube.engine.dispatch.BaseDispatchTask.run(BaseDispatchTask.java:64) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: weblogic.transaction.TimedOutException: Transaction timed out after 299 seconds BEA1-0672B035E0F02A163299 at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1614) ... 100 more
    Thanks
    Prashanth

    There is another way but I think it's more complicated.
    After reading the file you can use a java code (java embedded activity) and split the file.
    For each part of the split you can PUT by FTP the file with append mode. That way your transaction will run in few cycles with less time.

  • Transaction timeout? [solved]

    Hi,
    I am getting an time out when deploying a BPEL process:
    java.sql.SQLException: javax.resource.ResourceException: RollbackException: Transaktionen er markeret til tilbagestilling: Timed out
    I have found several posts regarding change the timeout via transaction-config timeout
    and transaction-timeout. My problem is that I can not find the files that is referenced in those posts. Maybe something has changed with release 10.1.3.1.0. Do anybody know where I have to change these now a days?
    Regards Pete

    We had problem when an asyncronous BPEL process called a syncronous BPEL process.
    We solved the problem changing every transaction-timeout in these files $ORACLE_HOME/j2ee/oc4j_soa/config/transaction-manager.xml,
    $ORACLE_HOME/j2ee/oc4j_soa/application-deployments/orabpel/ejb_ob_engine/orion-ejb-jar.xml,
    see also the Troubleshooting paragraph in the document b28981.pdf / Oracle BPEL Process Manager / Developer's Guide / Page A-1

  • Global Transaction Timeout

    Hi All-
    Lets say we have global transaction timeout set as 30 sec (transaction-manager.xml) and one of my database adapter is taking 10 mins to complete, is there any problem in that? DO we have to set any property on database adpater?
    The database adapter invoke, Is it a asynch or sync process?
    Regards,
    Sreejit

    Hi Shanmu,
    I am using release 10.1.3.3.0 and we are calling the database adapter to call the standard ERP api to import purchase order and it takes MAX time 10-15 minutes to complete the process.
    Major step in our bpel process:
    1. first activity is to receive the file polling, MAX 10 seconds.
    2. calls database adapter for logging purpose, creates one row in table, MAX time 10 seconds.
    3. Calls database adapter to validate and insert the 500 records, MAX time 10 seconds.
    4. Calls OA adapter to call the Oracle EBS R12 standard API to create Purchase order, MAX time 10-15 minutes.
    5. Calls database adapter to call the post update process, MAX time 5 minutes.
    6. deletes the file fileadapter, MAX time 2 sec
    7. Calls database adapter to update one row for logging purpose, MAX time 2 seconds.
    Current transaction timeout is set as 30 second in SOA_Oracle_Home\j2ee\home\config\transaction-manager.xml and 60 or somewhere 120 in SOA_Oracle_Home\j2ee\home\application-deployments\orabpel\ejb_ob_engine\orion-ejb-jar.xml
    Do you think that we need to increase the time out more than the time taking by the adapter No.4 and No. 5?
    And thanks for the information between 10g and 11g.
    Regards,
    Sreejit

  • Can't catch the exception when transaction rollback ,BPEL/SOA 11G,updated!

    Hi Guys ,
    I have two insert/update invoke actions through dbadpter in my BPEL process .
    When I set the GetActiveUnitOfWork property of those two db adapters to true ,it successfully makes the global transaction work . any of them failed will cause the other rollback.
    But the CatchAll brunch can't catch the exception in that case,
    I can only see exception message from the system output :
    02/11/2009 11:36:46 AM oracle.toplink.transaction.AbstractSynchronizationListener beforeCompletion
    WARNING:
    Local Exception Stack:
    Exception [TOPLINK-4002] (Oracle TopLink - 11g Release 1 (11.1.1.1.0) (Build 090527)): oracle.toplink.exceptions.DatabaseException
    Internal Exception: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (Table1_PK) violated
    from BPEL console , you can't even see the error , the process finished with no exception.
    When I set GetActiveUnitOfWork to false, CatchAll brunch is able to catch the exception , but global rollback is not working .
    I try all the other method like set the transaction property of BPEL to required , using checkpoint() in java embedding . it looks like only way is set GetActiveUnitOfWork to true, but can't catch exception.
    Here are some updated:
    Here is my process
    Main Sequence
    Invoke (dbadapter update)
    Invoke (dbadapter insert)
    Global CatchAll
    Invoke(jmsAdapter sendjms)
    if I disable the CatchAll branch , when insert failed , the insert will rollback as well, even GetActiveUnitOfWork set to false.
    enable CatchAll branch , even doing nothing in this branch , the update won't rollback when insert failed. it looks like when catch the exception , bpel seems not rollback , I try to add throw rollback in catchall branch, no any effect.
    any clue ?
    Kevin
    Edited by: kyi on Nov 5, 2009 10:10 AM

    Hi All,
    We are also facing a similar kind of issue.
    We have a simple BPEL which will makes use of JAva embedding to call an end point to check its availibility.
    The Java code for cheking the enpoint connectivity is below
    try{      
    boolean endpointAvailable = false;
    long start = System.currentTimeMillis();
    int endpointTestURL_port = 8445 ;
    int endpointTestURL_timeout = 500;
    String endpointTestURL_queryString = "" ;
    String endpointTestURL_protocol = (String)getVariableData ("endpointProtocol");
    addAuditTrailEntry("endpointTestURL_protocol: " + endpointTestURL_protocol);
    String endpointTestURL_host = (String)getVariableData ("endpointHost");
    addAuditTrailEntry("endpointTestURL_hostl: " + endpointTestURL_host);
    URL endpoint = new URL(endpointTestURL_protocol, endpointTestURL_host, 8445, endpointTestURL_queryString);
    addAuditTrailEntry("endpoint object is created" );
    String endpointTestURL = endpoint.toExternalForm();
    addAuditTrailEntry("Checking availability of endpoint at URL: " + endpointTestURL);
    // Configure connection
    HttpURLConnection connection = (HttpURLConnection)endpoint.openConnection();
    connection.setRequestMethod("GET");
    addAuditTrailEntry("The Method is Get");
    connection.setConnectTimeout(5000);
    addAuditTrailEntry("Timeout is 500 ms");
    // Open connection
    connection.connect();
    addAuditTrailEntry("Open Connection");
    String responseMessage = connection.getResponseMessage();
    addAuditTrailEntry("Recieved availability response from endpoint as: " + responseMessage);
    // Close connection
    connection.disconnect();
    endpointAvailable = true;
    if (endpointAvailable)
    setVariableData("crmIsAvailable", "true");
    else
    setVariableData("crmIsAvailable", "false");
    catch(Exception e)
    System.out.println ("Error in checking endpoint availability " + e) ;
    addAuditTrailEntry("error message is : " +e);         
    When we run the above as a seperate java program it runs fine i.e goes to the catch block and catches the exception.
    But when we run it within the java embedding in BPEL(11G) it gives us the follwoing error.
    The reason was The execution of this instance "490001" for process "default/GMDSSalesLeadsBackMediationInterface!1.0*soa_e1a6362f-c148-417c-819c-9327017ebfa4" is supposed to be in an active jta transaction, the current transaction status is "ROLLEDBACK" .
    Consult the system administrator regarding this error.
         at com.oracle.bpel.client.util.TransactionUtils.throwExceptionIfTxnNotActive(TransactionUtils.java:119)
         at com.collaxa.cube.engine.CubeEngine.store(CubeEngine.java:4055)
         at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:4372)
         at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:4281)
         at com.collaxa.cube.engine.CubeEngine._createAndInvoke(CubeEngine.java:713)
         at com.collaxa.cube.engine.CubeEngine.createAndInvoke(CubeEngine.java:545)
         at com.collaxa.cube.engine.delivery.DeliveryService.handleInvoke(DeliveryService.java:654)
         at com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(CubeDeliveryBean.java:355)
         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:597)
         at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
         at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
         at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
         at com.bea.core.repackaged.springframework.jee.intercept.MethodInvocationInvocationContext.proceed(MethodInvocationInvocationContext.java:104)
         at oracle.security.jps.ee.ejb.JpsAbsInterceptor$1.run(JpsAbsInterceptor.java:88)
         at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:313)
         at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:414)
         at oracle.security.jps.wls.JpsWeblogicEjbInterceptor.runJaasMode(JpsWeblogicEjbInterceptor.java:61)
         at oracle.security.jps.ee.ejb.JpsAbsInterceptor.intercept(JpsAbsInterceptor.java:106)
         at oracle.security.jps.ee.ejb.JpsInterceptor.intercept(JpsInterceptor.java:106)
         at sun.reflect.GeneratedMethodAccessor960.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:597)
         at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
         at com.bea.core.repackaged.springframework.jee.intercept.JeeInterceptorInterceptor.invoke(JeeInterceptorInterceptor.java:69)
         at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
         at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
         at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
         at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
         at com.bea.core.repackaged.springframework.jee.spi.MethodInvocationVisitorImpl.visit(MethodInvocationVisitorImpl.java:37)
         at weblogic.ejb.container.injection.EnvironmentInte
    we also get
    BEA1-108EA2A88DAF381957FF
    weblogic.transaction.internal.TimedOutException: Transaction timed out after 301 seconds
    BEA1-108EA2A88DAF381957FF
         at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(ServerTransactionImpl.java:1733)
         at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(ServerTransactionManagerImpl.java:1578)
         at weblogic.transaction.internal.TransactionManagerImpl.wakeUp(TransactionManagerImpl.java:1900)
         at weblogic.transaction.internal.ServerTransactionManagerImpl.wakeUp(ServerTransactionManagerImpl.java:1488)
         at weblogic.transaction.internal.WLSTimer.timerExpired(WLSTimer.java:35)
         at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
         at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
         at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
    javax.ejb.EJBException: Transaction Rolledback.: weblogic.transaction.internal.TimedOutException: Transaction timed out after 301 seconds
    BEA1-108EA2A88DAF381957FF
    We tried the following
    Increase the JTA timeout in the EM console to a larger value like 600 secs.
    The BPEL instance is not getting created.
    Any help would be appreciated
    Thanks
    Lalit

  • BMT and transaction timeout

    Hello,
    Does anybody knows what the behavior should be for a Session EJB with BMT (using JTA) after a transaction timeout? Does the container performs a database rollback for you immediately after the time-out event? I’ve noticed that JBoss does not perform a rollback but Web does. What do the J2EE specs say what should happen?
    We are experiencing database locks in an Oracle database caused by ‘hanging’ JTA-transactions which aren’t removed after a timeout. An application server restart will remove them. We are trying to find the cause, there fore I’am posting this message.
    Regards,
    Marteyn Heijlaerts

              "Laurel Neustadter" <[email protected]> wrote:
              >
              >Hi:
              >
              >The WLS 6.0 documentation states that for a CMT bean, one specifies the
              >transaction
              >timeout in weblogic-ejb-jar.xml, and for a BMT bean, one specifies the
              >transaction
              >timeout via UserTransaction.setTransactionTimeout().
              >
              >You also set a transaction timeout attribute at the domain level. How
              >does the
              >domain level attribute work into all of this? How is it used?
              >
              >For example, if a transaction timeout value is not specified at the bean
              >level,
              >will the domain level value be used?
              >
              >Laurel
              Yes, the domain level timeout is the default.
              It is overridden by any setting at the EJB level. This in turn
              can be overridden by the client calling the EJB, if the client
              starts a transaction and uses
              transactionManager.setTransactionTimeout()
              

  • Problem with transacted JMS connection factory and transaction timeouts

              We encountered an interesting problem using transacted JMS connection factories.
              An EJB starts a container managed transaction and tries to validate a credit card
              before creating some information to a database for the user, in case of success
              an SMS is sent to the user via the transacted JMS queue. If the credit card authentications
              duration is about the same as the transactions timeout (in this case the default
              30 seconds) sometimes the database inserts is committed but the JMS insert is
              rollbacked. How can this be?
              If the authorization duration is much longer than 30 seconds everything works
              fine (both database and JMS inserts rollbacked), the same is true if a rollback
              is insured by calling EJBContext.setRollbackOnly(). The problem thus occurs only
              if the duration is approximately the same as the transaction timeout, it appears
              that the database insert is not timeouted but the JMS insert is. How can this
              be if they are both participating in the same transaction.
              The JMSConnectionFactory used is a Connection factory with XA-enabled. The result
              is the same also with the default "javax.jms.QueueConnectionFactory" and if we
              configure our own factory with user transactions enabled.
              Any help appreciated!
              

    Tomas Granö wrote:
              > We encountered an interesting problem using transacted JMS connection factories.
              > An EJB starts a container managed transaction and tries to validate a credit card
              > before creating some information to a database for the user, in case of success
              > an SMS is sent to the user via the transacted JMS queue. If the credit card authentications
              > duration is about the same as the transactions timeout (in this case the default
              > 30 seconds) sometimes the database inserts is committed but the JMS insert is
              > rollbacked. How can this be?
              It should not be.
              >
              > If the authorization duration is much longer than 30 seconds everything works
              > fine (both database and JMS inserts rollbacked), the same is true if a rollback
              > is insured by calling EJBContext.setRollbackOnly(). The problem thus occurs only
              > if the duration is approximately the same as the transaction timeout, it appears
              > that the database insert is not timeouted but the JMS insert is. How can this
              > be if they are both participating in the same transaction.
              >
              > The JMSConnectionFactory used is a Connection factory with XA-enabled. The result
              > is the same also with the default "javax.jms.QueueConnectionFactory" and if we
              > configure our own factory with user transactions enabled.
              >
              > Any help appreciated!
              Make sure that your session is not "transacted". In other words,
              the first parameter to createSession() must be false. There is an
              unfortunate name re-use here. If a session is "transacted", it
              maintains an independent "inner transaction" independent of the
              outer transaction. From the above description, it seems unlikely
              that your application has this wrong, as you say that
              "setRollbackOnly" works - but please check anyway.
              Make sure that you are using a true XA capable driver and database
              (XA "emulation" may not suffice)
              Beyond the above, I do not see what can be going wrong. You
              may want to try posting to the transactions and jdbc newsgroups. Note
              that JMS is appears to be exhibiting the correct behavior, but the
              JDBC operation is not. The JDBC operation appears to have
              its timeout independent of the transaction monitor's timeout.
              Tom
              

  • Transaction timeouts of 242 seconds

    Hi All,
    I am getting transaction timeouts of 242 seconds. Can somebody help me where
    is this timeout value configured and how change it?
    Here We are Using Weblogic 8.1
    Stateless Session Bean, DAO, Servlets and JSPs
    The log file says as
    <DEBUG>SQLException: The transaction is no longer active - status: 'Marked rollback.
    [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out
    after 242 secon
    ds
    Name=[EJB com.hartfordlife.gbd.pvev.ejb.participantadmin.ParticipantAdministrationEJB.getPADownloadCaseCoverage(java.util.ArrayList,java.lang.String,java.lang.String)],Xid=BEA1-003
    0E44EFCA87F28EDB9(14529255),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
    since begin=242,seconds left=60,activeThread=Thread[ExecuteThread: '9' for queue:
    'weblo
    gic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTS
    XAResourceImpl]=(state=started,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@10c624a),SCInfo[mydomain+myserver]=(state=active),properties=({weblogic.transaction.name=[
    EJB com.hartfordlife.gbd.pvev.ejb.participantadmin.ParticipantAdministrationEJB.getPADownloadCaseCoverage(java.util.ArrayList,java.lang.String,java.lang.String)],
    weblogic.jdbc=t3:
    //157.209.165.64:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=myserver+157.209.165.64:7001+mydomain+t3+,
    XAResources={},NonXAResources={})],C
    oordinatorURL=myserver+157.209.165.64:7001+mydomain+t3+)]'. No further JDBC access
    is allowed within this transaction.
    <DEBUG>SQLErrorCode: 0
    <DEBUG>SQLState: null
    java.sql.SQLException: The transaction is no longer active - status: 'Marked rollback.
    [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out
    after 242 seconds
    Thanks in Advance
    Sai
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

    Unfortunately, it seems to work different in JBoss7. I created a very simple app and it waits until end of query execution instead of interrupting it.
    I'm porting application from weblogic to JBoss7 and it is critical for me to achieve identical behavior.

  • Transaction timeouts behaviour - explanation needed

    Hello all,
    I'm a newbie to Weblogic and would like to understand how transaction timeouts work in Weblogic. I have a EJB2 application running under Weblogic 10.3 and using Oracle 11g database via thin jdbc driver.
    I noticed that if I set trans-timeout-seconds in deployment descriptor it terminates sql queries if they overflow the limit. Say I have timeout set to 10 seconds, it will stop executing sql query after that time and immediately return exception to caller of the current EJB method. This is just perfect!
    What I want is to understand how that is done, does it proxy driver somehow? Will it work with other databases, Postgresql for example?
    Can I port same behavior to other app servers, JBoss for example.
    Thank you in advance.

    Unfortunately, it seems to work different in JBoss7. I created a very simple app and it waits until end of query execution instead of interrupting it.
    I'm porting application from weblogic to JBoss7 and it is critical for me to achieve identical behavior.

  • Working with Transactions in BPEL PM

    Hi,
    I am working on the Transactions in BPEL by solving the sample (<drive>\product\10.1.3.1\OracleAS_1\samples\tutorials\122.DBAdapter\advanced\dmlInvoke\*XAInsert*) provided in Oracle SOA suite samples. In this, I have performed by taking two different datasources as mentioned in the readme.txt and I am able to acheive the transaction functionality (provided in the sample inserting into two different datasources in a single commit.). However, this transaction is rolled back to the last commit point when there is any error in Insert2Service or Insert1Service. Here the BPEL instance will disapppear since there is no persistent point for this process.
    I have used the wait activity in the process before the both inserts to store the instance to the dehydration store, so whenever there is any exception I could see the instance hanging on the wait activity. It never executes any activities further the BPEL engine control is lost for this particular instance.
    I would like to know whether can we catch any type of exception thrown by Adapter framework and execute the necessary error handling code in the same BPEL process. Any suggestions. Ideas are welcome. Please throw some light if any of them have done BPEL Transactions with these kind of scenarios. (I am more insterested in doing it without the compensation handler concept.)
    Thanks in advamce.
    Regards,
    Rakesh

    Hi Anirudh,
    Thank you for the quick response.
    Let me give you brief exact desciption of my what I'm trying to achieve.
    I have BPEL process which is performing insert operations into two different databases. I'm trying to achieve this in a single Transaction for both inserts so I have set the transaction property for both Partner Links as "Participate" which enable both the inserts to perform in single transaction. I have already included the exception handler blocks for both the DB Insert calls and also has global exception handler for my BPEL process.
    But since I have set the transaction property whenever there is any exception in the second insert or in the first insert operation then BPEL control is lost, it never executes the exception block and instance is disappeared since thare is no commit point. So I have included wait activity before first Insert and now whenever there is any exception the instance rollbacks to wait activity which is the last commit point for my process and hangs there without any control and it never executes the exception block.
    Please help me in this scenario how to catch the DB exception in my process and do further error handling tasks.
    Let me know if you need further details.
    Thanks,
    Rakesh

  • Redelivery limit not working for transaction timeout?

    hi,
              we have a redelivery limit on a queue that works, except for when there is a transaction timeout. in this case, the message seems to be redelivered infinitely. Is this a bug? a feature?
              we are using Weblogic Server 8.1 SP4. we don't have the source code, so i am not sure how the error handling is done or what exceptions are thrown.
              ------------------ejb-jar.xml------------
              <message-driven>
              <ejb-name>ImporFileReceiver</ejb-name>
              <ejb-class>au.com.auspost.pcms.common.integration.ejb.mdb.ImporFileReceiverMdb</ejb-class>
              <transaction-type>Container</transaction-type>
              <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
              <message-driven-destination>
              <destination-type>javax.jms.Queue</destination-type>
              <subscription-durability>NonDurable</subscription-durability>
              </message-driven-destination>
              </message-driven>
              <container-transaction>
              <method>
              <ejb-name>ImporFileReceiver</ejb-name>
              <method-intf>Local</method-intf>
              <method-name>onMessage</method-name>
              <method-params>
              <method-param>javax.jms.Message</method-param>
              </method-params>
              </method>
              <trans-attribute>NotSupported</trans-attribute>
              </container-transaction>
              <container-transaction>
              <method>
              <ejb-name>ImporFileReceiver</ejb-name>
              <method-intf>Remote</method-intf>
              <method-name>onMessage</method-name>
              <method-params>
              <method-param>javax.jms.Message</method-param>
              </method-params>
              </method>
              <trans-attribute>NotSupported</trans-attribute>
              </container-transaction>
              ------------------------ weblogic-ejb-jar.xml ---------
              <weblogic-enterprise-bean>
              <ejb-name>ImporFileReceiver</ejb-name>
              <message-driven-descriptor>
              <pool>
              <max-beans-in-free-pool>10</max-beans-in-free-pool>
              <initial-beans-in-free-pool>10</initial-beans-in-free-pool>
              </pool>
              <destination-jndi-name>jms/pcmsImportFileQueue</destination-jndi-name>
              <connection-factory-jndi-name>jms/pcmsConnectionFactory</connection-factory-jndi-name>
              </message-driven-descriptor>
              <transaction-descriptor>
              <trans-timeout-seconds>3600</trans-timeout-seconds>
              </transaction-descriptor>
              <reference-descriptor>
              </reference-descriptor>
              <dispatch-policy>pcms.execute.queue.mdb.internal</dispatch-policy>
              <remote-client-timeout>0</remote-client-timeout>
              </weblogic-enterprise-bean>
              ------------------------ config.xml -----------------
              <JMSServer Name="eParcel JMS server"
              Store="eParcel JMS Server File Store" Targets="wls_pcms_prod1">
              <JMSQueue CreationTime="1190981682976"
              ErrorDestination="PCMS Import File Error Queue"
              JNDIName="jms/pcmsImportFileQueue"
              Name="PCMS Import File Queue" RedeliveryLimit="2"/>
              <JMSQueue CreationTime="1208347415759"
              JNDIName="jms/pcmsImportFileErrorQueue" Name="PCMS Import File Error Queue"/>
              </JMSServer>
              <JMSConnectionFactory JNDIName="jms/pcmsConnectionFactory"
              Name="eParcel JMS Connection Factory" Targets="wlc_pcms_prod"/>
              <JMSConnectionFactory JNDIName="jms/pcmsXAConnectionFactory"
              Name="eParcel JMS XA Connection Factory" Targets="wlc_pcms_prod" XAConnectionFactoryEnabled="true"/>
              -------------- weblogic log ---------------
              ####<24/04/2008 01:53:58 PM EST> <Warning> <EJB> <HX415> <wls_pcms_prod1> <ExecuteThread: '12' for queue: 'weblogic.kernel.Default'> <project_admin> <> <BEA-010065> <MessageDrivenBean threw an Exception in onMessage(). The exception was:
              javax.ejb.EJBException: Transaction Rolledback.: weblogic.transaction.internal.TimedOutException: Transaction timed out after 3599 seconds
              Name=[EJB au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerBean.handleMessage(org.apache.xmlbeans.XmlObject)],Xid=BEA1-696C9947A48195BA18DC(68926234),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=3599,seconds left=60,activeThread=Thread[ExecuteThread: '12' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@447373e,re-Registered = false),SCInfo[wlsd_auspost_prod+wls_pcms_prod1]=(state=active),properties=({weblogic.transaction.name=[EJB au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerBean.handleMessage(org.apache.xmlbeans.XmlObject)], weblogic.jdbc=t3://10.3.2.35:7003}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=wls_pcms_prod1+10.3.2.35:7003+wlsd_auspost_prod+t3+, XAResources={JMS_eParcel JMS Server File Store, weblogic, wlsd_auspost_prod, com},NonXAResources={})],CoordinatorURL=wls_pcms_prod1+10.3.2.35:7003+wlsd_auspost_prod+t3+)
              at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(I)V(ServerTransactionImpl.java:1614)
              at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(Ljava/util/List;I)V(ServerTransactionManagerImpl.java:1117)
              at weblogic.transaction.internal.TransactionManagerImpl.wakeUp()V(TransactionManagerImpl.java:1881)
              at weblogic.transaction.internal.ServerTransactionManagerImpl.wakeUp()V(ServerTransactionManagerImpl.java:1034)
              at weblogic.transaction.internal.WLSTimer.trigger(Lweblogic/time/common/Schedulable;)V(WLSTimer.java:31)
              at weblogic.time.common.internal.ScheduledTrigger.run()Ljava/lang/Object;(Optimized Method)
              at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Lweblogic/security/subject/AbstractSubject;Ljava/security/PrivilegedAction;)Ljava/lang/Object;(Optimized Method)
              at weblogic.security.service.SecurityManager.runAs(Lweblogic/security/acl/internal/AuthenticatedSubject;Lweblogic/security/acl/internal/AuthenticatedSubject;Ljava/security/PrivilegedAction;)Ljava/lang/Object;(SecurityManager.java:121)
              at weblogic.time.common.internal.ScheduledTrigger.executeLocally()V(ScheduledTrigger.java:229)
              at weblogic.time.common.internal.ScheduledTrigger.execute(Lweblogic/kernel/ExecuteThread;)V(ScheduledTrigger.java:223)
              at weblogic.kernel.ExecuteThread.execute(Lweblogic/kernel/ExecuteRequest;)V(Optimized Method)
              at weblogic.kernel.ExecuteThread.run()V(ExecuteThread.java:178)
              at java.lang.Thread.startThreadFromVM(Ljava/lang/Thread;)V(Unknown Source)
              ; nested exception is: weblogic.transaction.internal.TimedOutException: Transaction timed out after 3599 seconds
              Name=[EJB au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerBean.handleMessage(org.apache.xmlbeans.XmlObject)],Xid=BEA1-696C9947A48195BA18DC(68926234),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=3599,seconds left=60,activeThread=Thread[ExecuteThread: '12' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@447373e,re-Registered = false),SCInfo[wlsd_auspost_prod+wls_pcms_prod1]=(state=active),properties=({weblogic.transaction.name=[EJB au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerBean.handleMessage(org.apache.xmlbeans.XmlObject)], weblogic.jdbc=t3://10.3.2.35:7003}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=wls_pcms_prod1+10.3.2.35:7003+wlsd_auspost_prod+t3+, XAResources={JMS_eParcel JMS Server File Store, weblogic, wlsd_auspost_prod, com},NonXAResources={})],CoordinatorURL=wls_pcms_prod1+10.3.2.35:7003+wlsd_auspost_prod+t3+).

    Thanks Tom,
              Good point. The timeout exception is on ImportFileHandlerBean.handleMessage()....which is a session bean. The MDB must call this session bean, which also has a 3600 second timeout. It is confusing since the descriptor for the MDB has the transaction-timeout set, but i assume this is ignored for 'not-supported').
              I guess you would need to look at the code, but is there anyway a message go back on the queue, and not get the redelivery incremented?
              (I just had an evil thought...maybe the code could be physically sending the message onto the queue again when there is a timeout on the session bean.....hence would not get the redelivery incremented.....)
              -------------- ejb-jar.xml ----------------
              <session>
              <ejb-name>ImportFileHandler</ejb-name>
              <local-home>au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerLocalHome</local-home>
              <local>au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerLocal</local>
              <ejb-class>au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerBean</ejb-class>
              <session-type>Stateless</session-type>
              <transaction-type>Container</transaction-type>
              </session>
              ----------- weblogic-ejb.jar.xml -----------
              <weblogic-enterprise-bean>
              <ejb-name>ImportFileHandler</ejb-name>
              <stateless-session-descriptor>
              </stateless-session-descriptor>
              <transaction-descriptor>
              <trans-timeout-seconds>3600</trans-timeout-seconds>
              </transaction-descriptor>
              <reference-descriptor>
              </reference-descriptor>
              <enable-call-by-reference>True</enable-call-by-reference>
              <local-jndi-name>ejb/ImportFileHandlerLocal</local-jndi-name>
              <remote-client-timeout>0</remote-client-timeout>
              </weblogic-enterprise-bean>

  • Unreported Transaction timeout on commit (Oracle)

    I'm expecting an Oracle error upon commit using "deferred constraints" and
              executing an INSERT that should result in a constraint violation. I am not
              seeing an error but the transaction hangs for 30seconds (JTA timeout
              setting) and then continues without an exception. The session bean client
              has no indication that the transaction has failed.
              I've tried implicit and explicit transations from the client and the session
              bean is marked as required.
              Weblogic: 8.1 sp1
              DB: Oracle 8.1.6
              Driver: Oracle Thin XA
              How is it possible that Oracle fails upon commit but the JDBC connection
              waits for a timeout, and ALSO how is it possible that I'm not seeing a
              transaction timeout exception?
              (i've changed the JTA timeout setting to verify that this is the timeout
              that is occuring and sure enough if i make it 20 seconds it returns after
              20, 60, etc...)
              M
              

    Settings in Domain_name-JTA and Services-JTA are essentially the same settings. At least this is what I see - my changes to Services-JTA are reflected in Domain_name-JTA.
    Edited by: Valery_Cherepanov on 11.08.2012 14:32

  • Weblogic 7 SP5 SQL Exceptions follow a JTA transaction timeout

    I have a problem in Weblogic 7 SP5 that was not happening in SP2. I'm using the
    Weblogic jDriver (weblogic.jdbc.mssqlserver4.Driver)
    I have a transaction that times out due to JTA transaction timeout, and then gets
    marked for rollback. For several minutes after the timeout, I get many SQL Exceptions
    with bogus messages like "invalid column name" when the column name is, in fact,
    correct.
    Then the weblogic log file shows "Exception during rollback of transaction" (javax.transaction.SystemException:
    Heuristic hazard). Next, the connection is tested on reserve, this test fails,
    and the connection is refreshed. As soon as the connection is refreshed, I stop
    getting SQL exceptions and everything starts working correctly again.
    It seems like the transaction timeout is making the connection go bad, and somehow
    other requests are using this bad connection before the transaction finishes rolling
    back. What could the problem be? Some excerpts from my app log and weblogic log
    are below.
    com.workpoint.server.ejb.WorkPointEJBException: The transaction is no longer active
    - status: 'Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException:
    Transaction timed out after 901 seconds
    Name=[EJB com.storeperform.taskmgr.ejb.procrelease.ProcReleaseBean.distributeToOrgUnit(com.storeperform.taskmgr.values.DistributionUnit)],Xid=17109:68c10765ba68aaaa(12114044),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
    since begin=901,seconds left=60,activeThread=Thread[WorkQueueThread[q=1, qName=ProcReleaseTaskWorkers,
    id=6],5,WorkQueueGroup[id=1, name=ProcReleaseTaskWorkers]],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none,xar=weblogic.jdbc.jts.Connection@18cd616,re-Registered
    = false),SCInfo[DomainManager+edwards-s1]=(state=active),properties=({weblogic.transaction.name=[EJB
    com.storeperform.taskmgr.ejb.procrelease.ProcReleaseBean.distributeToOrgUnit(com.storeperform.taskmgr.values.DistributionUnit)],
    weblogic.jdbc=t3://10.10.3.17:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edwards-s1+10.10.3.17:7001+DomainManager+t3+,
    Resources={})],CoordinatorURL=edwards-s1+10.10.3.17:7001+DomainManager+t3+)]'.
    No further JDBC access is allowed within this transaction.SQL Command = INSERT
    INTO WP_PROCI_NODE_HIST (NODE_HIST_ID, NODE_HIST_DB, PROCI_ID, PROCI_DB, PROCI_NODE_ID,
    PROCI_NODE_DB, NODE_ITERATION, NODE_STATE_ID, ROW_VERSION, LU_ID, LU_DATE) VALUES
    weblogic.jdbc.mssqlserver4.TdsException: Invalid column name 'user_fname'.
    [from weblogic log]
    ####<Jun 17, 2004 8:14:16 AM MDT> <Error> <EJB> <EDWARDS> <edwards-s1> <WorkQueueThread[q=1,
    qName=ProcReleaseTaskWorkers, id=7]> <kernel identity> <> <010025> <Exception
    during rollback of transaction Name=[EJB com.storeperform.taskmgr.ejb.procrelease.ProcReleaseBean.distributeToOrgUnit(com.storeperform.taskmgr.values.DistributionUnit)],Xid=17439:68c10765ba68aaaa(31878774),Status=Rolled
    back. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException],HeuristicErrorCode=XA_HEURHAZ,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
    since begin=3,seconds left=57,ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=rolledback,assigned=edwards-s1,xar=weblogic.jdbc.jts.Connection@15e1b7e,re-Registered
    = false),SCInfo[DomainManager+edwards-s1]=(state=rolledback),properties=({weblogic.transaction.name=[EJB
    com.storeperform.taskmgr.ejb.procrelease.ProcReleaseBean.distributeToOrgUnit(com.storeperform.taskmgr.values.DistributionUnit)],
    weblogic.jdbc=t3://10.10.3.17:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edwards-s1+10.10.3.17:7001+DomainManager+t3+,
    Resources={})],CoordinatorURL=edwards-s1+10.10.3.17:7001+DomainManager+t3+): javax.transaction.SystemException:
    Heuristic hazard: (weblogic.jdbc.jts.Connection, HeuristicHazard, (javax.transaction.xa.XAException:
    I/O exception while talking to the server, java.io.EOFException))
    ####<Jun 17, 2004 8:14:17 AM MDT> <Warning> <JDBC> <EDWARDS> <edwards-s1> <ExecuteThread:
    '8' for queue: 'default'> <kernel identity> <> <001094> <A connection from pool
    "sp_connection_pool" was tested during reserve with the SQL "select 1" and failed:
    weblogic.jdbc.mssqlserver4.TdsException: I/O exception while talking to the server,
    java.io.EOFException
    ...[stack trace omitted]...
    This connection will now be refreshed.>

    Brad Swanson wrote:
    According to BEA's documentation, the jDriver is deprecated (no longer supported)
    in WLS 7 SP5. Not sure when they stopped supporting it, but sometime after SP2,
    apparently. Our solution, unfortunately, was to stay with SP2. Using the newer,
    supported JDBC driver would presumably fix the problem, but we didn't have time
    to do a full regression test with a different driver.Hi, no. The jDriver is deprecated, not unsupported. For WLS releases that contain
    the jDriver it will be supported for as long as we support the WLS release!
    Deprecation just means that we may choose to not supply that driver in any future
    release, and will not support it in that or any subsequent release.
    Practically, much depends on which jDriver you're using. In decreasing order
    of practical support we have: The weblogic.jdbc.oci.Driver to Oracle: We do actively
    continue to fix bugs in it. The weblogic.jdbc.mssqlserver4.Driver: Very unlikely that
    we will fix any new problem with it. The weblogic.jdbc.ifmx.Driver: Even less
    likely that we will do anything with it...
    I hope that makes it better for you.
    Joe

Maybe you are looking for