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.
Similar Messages
-
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
-
Hi,
From a bean's method whose transaction attribute is marked as
<Required>, I call another bean whose transaction attribute is marked as
<RequiresNew> (container managed transactions). When the container
suspends the first transaction and starts the second one, is the timeout
counter for the first transaction still ticking or is it also suspended
and resumed after the second transaction completes ?
Thanks, alex.
PS: I'm using WL6.0 (no servcie pack).
Alex Vauthey wrote:
> Bad news for us...
>
> We have a 'gateway' generic session bean that we use to run all business
> requests which in turn can call other session beans or entity beans. So
> the timeout of my 'gateway' session bean has to have a timeout value
> that is the highest possible sum of the timeouts of all called beans ?
> That's bad, because in some cases the gateway should execute quite quickly.
>
It sounds like your gateway bean needs different semantics. It probably
shouldn't hold open a transaction while it calls the other beans.
It's hard to tell you what to do without more info, but bean-managed
transactions possibly with a compensating transaction may be the way to go.
> I'm disappointed the ejb specs did not specify what 'suspended' really
> means... So each container vendor has its very own idea of what
> 'suspended' means, I suppose.
Not really. EJB just has a flat transaction model.
-- Rob
>
> Any idea to cope with that problem without breaking the generic gateway
> approach ?
>
> Rgrds, alex.
>
> Rob Woollen wrote:
>
>> The timer keeps ticking. Suspend is a bad name for this because
>> really the transaction is still active, it's just no longer associated
>> with the current thread.
>>
>> -- Rob
>>
>> PS WLS 6.0 no service pack is a bad way to go. We've fixed lots of
>> bugs since then. I'd suggest 6.1SP3 or 7.0.
>>
>>
>> Alex Vauthey wrote:
>>
>>> Hi,
>>>
>>> From a bean's method whose transaction attribute is marked as
>>> <Required>, I call another bean whose transaction attribute is marked
>>> as <RequiresNew> (container managed transactions). When the container
>>> suspends the first transaction and starts the second one, is the
>>> timeout counter for the first transaction still ticking or is it also
>>> suspended and resumed after the second transaction completes ?
>>>
>>> Thanks, alex.
>>>
>>> PS: I'm using WL6.0 (no servcie pack).
>>
>>
>
> --
>
> Alexandre Vauthey
> Server Technology Mgr.
> Application Networks
> 444 Ramona Street
> Palo Alto, CA 94301
>
> Tel: 1 (650) 462 7224
> Fax: 1 (650) 462 7221
>
> www.application-networks.com <http://www.application-networks.com/>*
> <http://www.application-networks.com/>*
>
>
> <http://www.application-networks.com/>
>
> *
> <http://www.application-networks.com/>*
>
>
>
>
-
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. -
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 -
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
PrashanthThere 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. -
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 -
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! -
I am doing some testing to reproduce a production scenario where we ended up with messages stuck in JMS queue in receive state ( weblogic 10.3.3)...
The flow is as below:
JMS Queue --> Transactional MDB with resource reference
The MDB makes a callout to http service . No read time out configured for the http invocation
Transaction Timeout : 10 minutes for the MDB
I put a Thread.sleep in the target http service for 11 minutes
Tested by placing a message in the queue. MDB picked the message and made http call. Message substate was receive-transaction. Queue had redelivery delay of 55 seconds and redelivery limit of -1.
I would like to know what is the designed behaviour in this scenario when transaction timeout occurs at 10 minutes. ?
The behaviour I observed,
From JTA Monitoring ,At 602nd second, transaction was marked for rolled back, though the MDB code was executing [ I think this is the correct behaviuor]
Message substate was receieve-transaction till end of 660th second, when it got redelivered. Redelivery count increased by 1. I was expecting message substate to change to delayed, but it didn't,. New substate after 660th second was also receive transaction. In JTA monitoring I could also see a new transaction spawning up.
The whole purpose of my experiment was to reproduce the scenrio we are observing messages in 'receive' state when http service goes out. Any suggestion how i can get this, all I could get is receive transaction.
Thanks In Advance.So if the delay is set to 11 minutes, but the message is trapped in a receive transaction that times out after 10 minutes, there will only be a 1 minute redelivery delay... Thanks Tom. This is eaxctly the behaviour I am observing. And if redelivery delay is less than transaction timeout period, message is redelivered instantaneously when the transaction timeout occurs.
It seems you're looking into the final details of the "redelivery delay" feature's behavior? I am looking at how to trap the message in receive state. We are seeing messages stuck in receive state in production when http service goes out and it occurs randomly. My guess is since we have not configured http read time out, the socket timeout occurs at a time beyond transaction timeout and some of the complex underlying behaviours at transaction timeout event is the reason for this [ could even be a bug when dealing with this abnormal condition].
A solution for this is to set out the http read time out less than transaction timeout. We have done this in prod now and since we cant reproduce the issue , we dont know whether it fixes the problem. We are now waiting to see if the issue reoccurs . The customer doesn't like this and wants us to reproduce the issue for confirmation.
I am looking at the message substate transitions. I know for transactional weblogic MDB's and non UOO messages, the state transition will be :
Visible --> receive --> receive transaction --> transaction committed or rolled back
In this transition , it is possible for messge in receive transaction to revert back to receive status ?
P.S. we have spent huge amount of time and effort with Oracle support with no real solutions. They want us to tell them the method to reproduce the issue. -
Changeing Transaction timeouts
Hi..
While trying to tune the WLI ejbs, I came across the following documentation
on edocs.bea.com. It mentions to change the trans-timeout-seconds attribute
for the wlpi-ejb.jar file.
But when I accessed the ejb descriptor using weblogic console, I could not
find the trans-timeout-seconds attribute in the ejb-jar.xml. Can anyone
please inform me where to find it ?
Configuring EJB Transactions
If your system returns an exception indicating that a transaction timed out
while a message was being processed, we recommend that you tune the
transaction timeout parameters in the following BPM resources:
a.. WLI-BPM Server (wlpi-ejb.jar)
b.. WLI-BPM Event Processor EJB (wlpi-mdb-ejb.jar)
Note: Transaction timeouts are more likely to occur when large messages,
rather than small messages, are being processed.
To tune the transaction timeout parameters, we recommend that you change the
trans-timeout-seconds attribute in the wlpi-ejb.jar and wlpi-mdb-ejb.jar
files from 90 seconds to 1090 seconds. To access the JAR files:
1.. In the Administration Console navigation tree, select
Deployments->EJB.
2.. Select WLI-BPM Server EJB or WLI-BPM Event Processor EJB.
3.. Click Edit EJB Descriptor to display a new window in which you can
edit the EJB descriptor.
Thanks..
MandarHi,
The trans time out value is set in "weblogic-ejb-jar.xml" Choose edit EJB descriptor
for BPM server,In wlpi-ejb.jar, there are three jars, choose weblogic EJB jar.
You can find the Transaction descriptor in Weblogic Enterprise beans.
Regards,
Anandhi
"Mandar Gandhe" <[email protected]> wrote:
Hi..
While trying to tune the WLI ejbs, I came across the following documentation
on edocs.bea.com. It mentions to change the trans-timeout-seconds attribute
for the wlpi-ejb.jar file.
But when I accessed the ejb descriptor using weblogic console, I could
not
find the trans-timeout-seconds attribute in the ejb-jar.xml. Can anyone
please inform me where to find it ?
Configuring EJB Transactions
If your system returns an exception indicating that a transaction timed
out
while a message was being processed, we recommend that you tune the
transaction timeout parameters in the following BPM resources:
a.. WLI-BPM Server (wlpi-ejb.jar)
b.. WLI-BPM Event Processor EJB (wlpi-mdb-ejb.jar)
Note: Transaction timeouts are more likely to occur when large messages,
rather than small messages, are being processed.
To tune the transaction timeout parameters, we recommend that you change
the
trans-timeout-seconds attribute in the wlpi-ejb.jar and wlpi-mdb-ejb.jar
files from 90 seconds to 1090 seconds. To access the JAR files:
1.. In the Administration Console navigation tree, select
Deployments->EJB.
2.. Select WLI-BPM Server EJB or WLI-BPM Event Processor EJB.
3.. Click Edit EJB Descriptor to display a new window in which you
can
edit the EJB descriptor.
Thanks..
Mandar -
Transaction timeout when two system communicate by web service.
Currently, our application run under WLS 10, and exchange data with another system build on WLS 10 also by web service.
These two system both set global transaction timeout through Console: Server-->Configuration-->JTA-->Timeout Seconds, set number is 1800s.
Long time operation within one system is ok, never meet tracation timeout exception. But, when one system call another system via web service, always meet below exception(same operation run under wls 8.1 is ok):
15-02-2008@17:35:56 ERROR leave : [[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] [CTLeaveWebService@PSA] [B2E_CTLeave.Get_Leave_Info] Exception Occured, Failure creating new instance of RowMapper, org.apache.beehive.controls.api.ControlException: RowToObjectMapper: SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: Transaction rolled back: Transaction timed out after 30 seconds
BEA1-067F39AED8C5E04484B3
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.GeneratedConstructorAccessor136.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)
at com.psa.citos.rms.leave.services.resouces.StaffLeaveDBBean.getLeaveDetailsByLvEmpIdStDtEndDtStatusInArray(StaffLeaveDBBean.java:198)
at com.psa.citos.rms.leave.services.bizlogic.StaffLeaveServiceImpl.getLeaveDetailsByLvEmpIdStDtEndDt(StaffLeaveServiceImpl.java:276)
at com.psa.citos.rms.leave.services.bizlogic.StaffLeaveServiceBean.getLeaveDetailsByLvEmpIdStDtEndDt(StaffLeaveServiceBean.java:1112)
at com.psa.citos.rms.leave.services.bizlogic.LeaveServiceImpl.getLeaveDetailsByLvEmpIdStDtEndDt(LeaveServiceImpl.java:337)
at com.psa.citos.rms.leave.services.bizlogic.LeaveServiceBean.getLeaveDetailsByLvEmpIdStDtEndDt(LeaveServiceBean.java:596)
at com.psa.citos.rms.leave.facades.WebServiceFacadesImpl.getStaffLeaveInfoForRoster(WebServiceFacadesImpl.java:254)
at com.psa.citos.rms.leave.facades.WebServiceFacadesBean.getStaffLeaveInfoForRoster(WebServiceFacadesBean.java:250)
at com.psa.citos.rms.leave.webservice.CTLeaveWebService.getLeaveInfo(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at weblogic.wsee.component.pojo.JavaClassComponent.invoke(JavaClassComponent.java:99)
at weblogic.wsee.ws.dispatch.server.ComponentHandler.handleRequest(ComponentHandler.java:64)
at weblogic.wsee.handler.HandlerIterator.handleRequest(HandlerIterator.java:123)
at weblogic.wsee.ws.dispatch.server.ServerDispatcher.dispatch(ServerDispatcher.java:85)
at weblogic.wsee.ws.WsSkel.invoke(WsSkel.java:80)
at weblogic.wsee.server.servlet.SoapProcessor.handlePost(SoapProcessor.java:66)
at weblogic.wsee.server.servlet.SoapProcessor.process(SoapProcessor.java:44)
at weblogic.wsee.server.servlet.BaseWSServlet$AuthorizedInvoke.run(BaseWSServlet.java:257)
at weblogic.wsee.server.servlet.BaseWSServlet.service(BaseWSServlet.java:156)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3392)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2140)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2046)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
[java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: Transaction rolled back: Transaction timed out after 30 seconds
Data Sourse config:
URL: jdbc:oracle:thin:@xxxxxx:1521:xxxxxx
Driver Class Name: oracle.jdbc.xa.client.OracleXADataSource
Can help to advise what this exception cause and how to resolve?
thanks and best regards.
Edited by rendlut at 02/17/2008 7:29 PM
Edited by rendlut at 02/17/2008 7:38 PMr c wrote:
> Currently, our application run under WLS 10, and exchange data with another system build on WLS 10 also by web service.
> These two system both set global transaction timeout through Console: Server-->Configuration-->JTA-->Timeout Seconds, set number is 1800s.
>
> Long time operation within one system is ok, never meet tracation timeout exception. But, when one system call another system via web service, always meet below exception(same operation run under wls 8.1 is ok):
>
> 15-02-2008@17:35:56 ERROR leave : [[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] [CTLeaveWebService@PSA] [B2E_CTLeave.Get_Leave_Info] Exception Occured, Failure creating new instance of RowMapper, org.apache.beehive.controls.api.ControlException: RowToObjectMapper: SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: Transaction rolled back: Transaction timed out after 30 seconds
> BEA1-067F39AED8C5E04484B3
> 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.GeneratedConstructorAccessor136.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)
> at com.psa.citos.rms.leave.services.resouces.StaffLeaveDBBean.getLeaveDetailsByLvEmpIdStDtEndDtStatusInArray(StaffLeaveDBBean.java:198)
> at com.psa.citos.rms.leave.services.bizlogic.StaffLeaveServiceImpl.getLeaveDetailsByLvEmpIdStDtEndDt(StaffLeaveServiceImpl.java:276)
> at com.psa.citos.rms.leave.services.bizlogic.StaffLeaveServiceBean.getLeaveDetailsByLvEmpIdStDtEndDt(StaffLeaveServiceBean.java:1112)
> at com.psa.citos.rms.leave.services.bizlogic.LeaveServiceImpl.getLeaveDetailsByLvEmpIdStDtEndDt(LeaveServiceImpl.java:337)
> at com.psa.citos.rms.leave.services.bizlogic.LeaveServiceBean.getLeaveDetailsByLvEmpIdStDtEndDt(LeaveServiceBean.java:596)
> at com.psa.citos.rms.leave.facades.WebServiceFacadesImpl.getStaffLeaveInfoForRoster(WebServiceFacadesImpl.java:254)
> at com.psa.citos.rms.leave.facades.WebServiceFacadesBean.getStaffLeaveInfoForRoster(WebServiceFacadesBean.java:250)
> at com.psa.citos.rms.leave.webservice.CTLeaveWebService.getLeaveInfo(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at weblogic.wsee.component.pojo.JavaClassComponent.invoke(JavaClassComponent.java:99)
> at weblogic.wsee.ws.dispatch.server.ComponentHandler.handleRequest(ComponentHandler.java:64)
> at weblogic.wsee.handler.HandlerIterator.handleRequest(HandlerIterator.java:123)
> at weblogic.wsee.ws.dispatch.server.ServerDispatcher.dispatch(ServerDispatcher.java:85)
> at weblogic.wsee.ws.WsSkel.invoke(WsSkel.java:80)
> at weblogic.wsee.server.servlet.SoapProcessor.handlePost(SoapProcessor.java:66)
> at weblogic.wsee.server.servlet.SoapProcessor.process(SoapProcessor.java:44)
> at weblogic.wsee.server.servlet.BaseWSServlet$AuthorizedInvoke.run(BaseWSServlet.java:257)
> at weblogic.wsee.server.servlet.BaseWSServlet.service(BaseWSServlet.java:156)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
> at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
> at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
> at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
> at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3392)
> at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
> at weblogic.security.service.SecurityManager.runAs(Unknown Source)
> at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2140)
> at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2046)
> at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366)
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
> at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
> [java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: Transaction rolled back: Transaction timed out after 30 seconds
>
> Data Sourse config:
> URL: jdbc:oracle:thin:@xxxxxx:1521:xxxxxx
> Driver Class Name: oracle.jdbc.xa.client.OracleXADataSource
>
>
> Can help to advise what this exception cause and how to resolve?
>
> thanks and best regards.
>
> --
> Edited by rendlut at 02/17/2008 7:29 PM
>
> --
> Edited by rendlut at 02/17/2008 7:38 PM
In the console, you can set the JTA timeout to
something more appropriate for your needs than
the default 30 seconds.
Joe -
Hello all
Problem...
I am retrieving approx 1200 records from an Oracle database via an CMP EJB findByXXXXX method. The problem is my Transaction times out after 30 seconds.
What I have already done...
I'm using Weblogic 6.0 and have configured the JTA to timeout after 2 minutes. However, I'm still getting a Transaction timeout exception after only 30 seconds. I would Appreciate any help. Thank-you....
Mark.Sounds like you might be running into this bug:
http://newsgroups.bea.com/cgi-bin/dnewsweb?cmd=article&group=weblogic.developer.interest.transaction&item=379&utag= -
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,
SreejitHi 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
Maybe you are looking for
-
hi, any one can give me definations of SALES OREDR,QUATATION,PURCHASE ORDER,INVOICE,DELIVERY,COMPANY CODE,SALES ORGANIZATION,PLANT,WARE HOUSE.
-
Sandisk cruzer flash drive and iphoto
everytime i insert my sandisk usb flash drive, iphoto launches automatically ready to import photos, even when there's no photos to import. i usually just command-Q to quit iphoto, but it gets annoying to do it everytime, especially when all i want t
-
Macbook Air 11" 2012 screen failure?
Wondering how many others have had problems with screen failure on this particular model? I purchased march of 2012. I read elswhere that they were having issues with displays that were not Samsung brand. I just had to pay to replace at 16 months;
-
Nearly every time I try to login (either root or user) I get a blank screen for about 15 seconds and then turns into diagonal lines. I hit ctrl+alt+bksp and it takes me back to the login. I change the session to last and log in again and everything c
-
When i run a report. It runs fine. but when i try to run it in backgroound, it throws this error."OBJECTS_NOT_CHARLIKE". At the statment "STRLEN( obj )..." , only character-type data objects are supported at the argument position "obj". In this parti