Transaction Timeout behaviour

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.

Similar Messages

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

  • Blocking vs transactional timeout

    Hello all,
    I'm having some questions regarding timeout handling that I would appreciate your
    thoughts (and facts!) on.
    When my client makes a tpcall() it will be subject to a blocking timeout which
    is just fine by me (I don't want to wait forever). The problem is that when I
    get the blocking timeout and report an error to the user, the service may have
    completed the work in the "background" just fine (just a bit slower than normal).
    This means that I'm reporting an error when the service worked OK, which may seem
    a bit confusing to the user.
    Plan B would be to use a client-initiated transaction with a transaction time-out.
    In this case I would know that a time-out would mean that the transaction would
    be rollback-only and there would be no doubt that the user's operation failed.
    This is clearly a better behaviour. On the other hand, it would imply a re-write
    of some rather sensitive and well tested code... and I guess that tpcommit() would
    add another round-trip to the server from my time-critical /WS client. (Would
    tpbegin() add a round-trip, too?)
    I'm therefore thinking of a Plan C instead. What would AUTOTRAN and TRANTIME add
    to this situation? Would TRANTIME override the blocking timeout? Normally a transactional
    timeout overrides a blocking time-out, but is an AUTOTRAN transaction "logically"
    started by the client (meaning transactional timeout overrides blocking) or by
    the service (meaning that a "slow" service simply fails at commit-time and the
    client is still subject to a possibly different blocking timeout)?
    Any input on this welcome,
    /Per

    In Plan C, a client won't know that a service is running in AUTOTRAN mode, so it
    will still be subject to BLOCKTIME.
    To get more control, use tpacall/tpgetrply. If the tpgetrply returns with a
    timeout, you can decide whether to try it again if you think your service is
    taking a little too long.
    A more complex architecture could use a conversational service, with a thread to
    do the actual work, and a thread to send back periodic "I'm still working"
    messages. Sort of an application-velel keepalive. If you don't even get the "I'm
    still working message" after BLOCKTIME, then you can give up.
         Scott
    Per Lindström wrote:
    Hello all,
    I'm having some questions regarding timeout handling that I would appreciate your
    thoughts (and facts!) on.
    When my client makes a tpcall() it will be subject to a blocking timeout which
    is just fine by me (I don't want to wait forever). The problem is that when I
    get the blocking timeout and report an error to the user, the service may have
    completed the work in the "background" just fine (just a bit slower than normal).
    This means that I'm reporting an error when the service worked OK, which may seem
    a bit confusing to the user.
    Plan B would be to use a client-initiated transaction with a transaction time-out.
    In this case I would know that a time-out would mean that the transaction would
    be rollback-only and there would be no doubt that the user's operation failed.
    This is clearly a better behaviour. On the other hand, it would imply a re-write
    of some rather sensitive and well tested code... and I guess that tpcommit() would
    add another round-trip to the server from my time-critical /WS client. (Would
    tpbegin() add a round-trip, too?)
    I'm therefore thinking of a Plan C instead. What would AUTOTRAN and TRANTIME add
    to this situation? Would TRANTIME override the blocking timeout? Normally a transactional
    timeout overrides a blocking time-out, but is an AUTOTRAN transaction "logically"
    started by the client (meaning transactional timeout overrides blocking) or by
    the service (meaning that a "slow" service simply fails at commit-time and the
    client is still subject to a possibly different blocking timeout)?
    Any input on this welcome,
    /Per

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

  • 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

  • Set Transaction timeout in Jdeveloper

    hi,
    I am using Jdeveloper 11.1.1.5 with JPA2.0. Is there an option where i can set the JTA Timeout for the integrated WLS server.
    I know how to do it using the Web Console, however Id like to be able to do it either from a Jdeveloper setting or maybe a configuration file.
    Any help is much appreciated.
    Thanks

    what is Transaction timeout in ATGTransaction timeout is related to application server. For more detail see below urls:
    http://docs.oracle.com/cd/E36434_01/Platform.10-1-2/ATGEndecaIntegrationGuide/html/s0106increasingthetransactiontimeouta01.html
    http://docs.oracle.com/cd/E24152_01/Platform.10-1/ATGInstallGuide/html/s0406settingthetransactiontimeoutonwe01.html
    http://docs.oracle.com/cd/E24152_01/Platform.10-1/ATGInstallGuide/html/s0406settingthetransactiontimeoutonjb01.html
    -RMishra
    Edited by: RMishra on Mar 14, 2013 5:53 PM
    Edited by: RMishra on Mar 14, 2013 6:10 PM

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

  • Wls 10.3 weblogic-webservices.xml transaction-timeout attribute not working

    Hi, need some urgent need.
    I have a stateless ejb webservice and I'm trying to set the transaction timeout for some of the methods. Right now my webservice transaction is timing out to the default of 30 secs. I've tried setting in the admin console the JTA transaction timeout option, didn't work (file a case with bea support #81233). And after days of researching and searching I came across that you can setup the weblogic webservice transaction-timeout thru the weblogic-webservices.xml deployment descriptor. Tried setting the transaction-timeout attribute to 120 secs. and that didn't work. Here is the snippet of the xml file.
    <?xml version='1.0' encoding='UTF-8'?>
    <weblogic-webservices xmlns="http://www.bea.com/ns/weblogic/weblogic-webservices" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-webservices http://www.bea.com/ns/weblogic/weblogic-webservices/1.0/weblogic-webservices.xsd">
    <webservice-description>
    <webservice-description-name>com.starcomsoft.pp.system.jws.SystemWSImpl</webservice-description-name>
    <webservice-type>JAXRPC</webservice-type>
    <port-component>
    <port-component-name>SystemWSSoapPort</port-component-name>
    <service-endpoint-address>
    <webservice-contextpath>starcomsoft_ws</webservice-contextpath>
    <webservice-serviceuri>/SystemWSImpl</webservice-serviceuri>
    </service-endpoint-address>
         <transaction-timeout>120</transaction-timeout>
         <reliability-config>
              <inactivity-timeout>P0DT600S</inactivity-timeout>
         </reliability-config>
    </port-component>
    </webservice-description>
    </weblogic-webservice>
    Does anybody have any clue to solve my urgent need.
    Thanks in advance for your help or suggestion.

    Unhandled exception
    Type=Segmentation error vmState=0x00040000
    J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000033
    Handler1=F144C588 Handler2=F1446A9C
    Module=/app/oracle/product/Middleware/wlserver_10.3/server/native/aix/ppc/libmuxer.so
    Module_base_address=D8457000
    Target=2_40_20091214_049398 (AIX 5.3)
    CPU=ppc (4 logical CPUs) (0x600000000 RAM)
    ----------- Stack Backtrace -----------
    (0xD696E748 [libj9vm24.so+0x48748])
    (0xD8383EDC [libjclscar_24.so+0x10edc])
    (0xD8384514 [libjclscar_24.so+0x11514])
    (0xD6967718 [libj9vm24.so+0x41718])
    (0xD6967158 [libj9vm24.so+0x41158])
    (0xD69640D0 [libj9vm24.so+0x3e0d0])
    (0xD6932C9C [libj9vm24.so+0xcc9c])
    (0xD69BBA18 [libj9prt24.so+0x3a18])
    (0xD6932BB8 [libj9vm24.so+0xcbb8])
    (0xD69A77CC [libj9thr24.so+0x27cc])
    pthreadbody+0x118 (0xD010D784 [libpthreads.a+0x3784])

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

    Hi,
    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

Maybe you are looking for

  • Apple Loops no longer work!!!

    Hi I have a strange problem. I imported an apple loop from the Library>Audio folder into ProTools via drag and drop. Pro Tools created a copy of the audio file in the local ProTools audio folder. Strange thing is now the OS and all the iLife apps can

  • Check on Settlement Rule in IW31

    Hi, I have to keep check on Settlement Rule in IW31. i have to compare the first four characters of Settlement rule with that of Planning Plant. If both are not equal an error message should be raised. For example Settlement Rule--->1600009  and if p

  • How can you tell what pictures from iPhoto you already used in iMovie?

    how can you tell what pictures from iPhoto you already used in iMovie?

  • Canon 5D Mark III Jpeg problem

    Received my new 5D Mark iii today. Pretty happy so far however I have noticed a strange issue with Apple Aperture when viewing jpegs from the 5d mark iii. I noticed a white line at the top of the frame or the left of the frame on vertical shots. It i

  • Solutions for Lack of DVD Drive?

    I have a "vintage" G4 from 2001. I want to upgrade it to OS 10.5 (Leopard) from 10.4. The problem is it does not have a DVD drive, only a CD drive. I have access to an external Apple DVD drive that my husband got for his Air that I thought I'd be abl