Monitor EJB transaction timeout value

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

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

Similar Messages

  • JTA transaction timeout vs. EJB transaction timeout

    Hi,
    can anybody tell me if the JTA transaction timeout, e.g. <JTA
    Name="myServer" TimeoutSeconds="60"/> works for EJBs as default transaction
    timeout if none is given in the deployment descriptor.
    I assumed that this is correct, and tried to test this by setting the
    JTA-timeout value to 1 (second). However I experienced no timeout exceptions
    in our logfile with this setting.
    Regards
    Andi
    +49 69 263-87303, [email protected]

    Thanks, Rob
    "Rob Woollen" <[email protected]> schrieb im Newsbeitrag
    news:[email protected]..
    This should work fine in 6.1 and 7.0. I believe it was broken in 6.0
    -- Rob
    Andreas Bittorf wrote:
    Hi,
    can anybody tell me if the JTA transaction timeout, e.g. <JTA
    Name="myServer" TimeoutSeconds="60"/> works for EJBs as default
    transaction
    timeout if none is given in the deployment descriptor.
    I assumed that this is correct, and tried to test this by setting the
    JTA-timeout value to 1 (second). However I experienced no timeoutexceptions
    in our logfile with this setting.
    Regards
    Andi
    +49 69 263-87303, [email protected]

  • Ocj4 ejb transaction-timeout

    I've got the following in my orion-ejb-jar.xml:
    <session-deployment name="..." transaction-timeout="900"/>
    OC4J appears to ignore it. For one, I get transaction timeouts with operations lasting less than 900 seconds. For two, I see in the EM MBean browser that the transaction timeout for the stateless session bean has a value of "-1".
    Am I doing something wrong, or is OC4J broken?

    Anybody out there?
    I'm sure I can't be the only one trying to do this...

  • EJB Transaction timeout and Statement Query Timeout

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

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

  • Impost a EJB transaction timeout

              Hello...
              I have a problem....I need to impost a transaction timeout on a stateless ejb
              call
              without generate the transaction but only with a new Context and the successive
              lookup.
              This for return the ejb called in case witch this then called another another
              remote ejb but this not give response......so that I can make finish the transaction
              first that the second ejb goes in timeout...
              Is this possible with the stateless ejb also setting some weblogic parameter?
              I work with an J2EE 2.0 application under WLS6.1 SP5 .
              thanks.
              

              This isn't really possible. If your second bean throws an exception if it doesn't
              respond then you can always catch this and call setRollbackOnly() (or let the
              container do this for you); if however the second bean doesn't respond and blocks
              for a long time, then the transaction timeout won't help. WebLogic implements
              the transaction timeout on another thread so it can keep good time, but can only
              signal your bean when it tries to do something transactional - and if it's blocked
              in another method this might not happen.
              simon.
              "rion" <[email protected]> wrote:
              >
              >Hello...
              >I have a problem....I need to impost a transaction timeout on a stateless
              >ejb
              >call
              >without generate the transaction but only with a new Context and the
              >successive
              >lookup.
              >This for return the ejb called in case witch this then called another
              >another
              >remote ejb but this not give response......so that I can make finish
              >the transaction
              >first that the second ejb goes in timeout...
              >Is this possible with the stateless ejb also setting some weblogic parameter?
              >I work with an J2EE 2.0 application under WLS6.1 SP5 .
              >thanks.
              >
              

  • EJB Transaction Timeout

    Hi,
    we have set the following in bc4j.xcfg for our AppicationModule which is deployed as EJB with BMT:
    <jbo.ejb.txntimeout>0</jbo.ejb.txntimeout>
    With jbo.debugoutput=console we get the following lines
    including "Transaction timeout set to 0 secs"
    [298] Diagnostic Properties: Timing:false Functions:false Linecount:true Threshold:6
    [299] Loading from /de/materna/heimabrechnung/common/logging/logging.xml file
    [300] Loading from indvidual XML files
    [301] Loading the Containees for the Package 'de.materna.heimabrechnung.common.logging.logging'.
    [302] Loading from /de/materna/heimabrechnung/common/logging/LoggingModule.xml file
    [303] Loading from /de/materna/heimabrechnung/common/logging/LogEintragView.xml file
    [304] Loading from /de/materna/heimabrechnung/common/logging/LogEintrag.xml file
    [305] Loading from /de/materna/heimabrechnung/common/logging/LogStacktraceView.xml file
    [306] Loading from /de/materna/heimabrechnung/common/logging/LogStacktrace.xml file
    [307] mUsePersColl is false
    [308] ViewObjectImpl.mDefaultMaxRowsPerNode is 70
    [309] ViewObjectImpl.mDefaultMaxActiveNodes is 30
    [310] Transaction timeout set to 0 secs
    [311] Created root application module: 'de.materna.heimabrechnung.common.logging.LoggingModule'
    [312] Locale is: 'en'
    [313] Transaction timeout set to 0 secs
    [314] Trying connection: DataSource='com.evermind.sql.OrionCMTDataSource/heimabrechnung/jdbc/HeimabrechnungDS'...
    [315] Successfully logged in
    But after a while not using the ApplicationModule on the client the server throws the following exception:
    java.lang.NullPointerException
    at oracle.jbo.server.remote.ejb.EJBApplicationModuleImpl.resumeTransaction(EJBApplicationModuleImpl.java:635)
    at de.materna.heimabrechnung.common.logging.server.ejb.beanmanaged.LoggingModuleServer.logDebug(LoggingModuleServer.java:6
    0)
    at RemoteLoggingModule_StatefulSessionBeanWrapper20.logDebug(RemoteLoggingModule_StatefulSessionBeanWrapper20.java:1383)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
    at com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
    at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:802)
    at java.lang.Thread.run(Thread.java:484)
    Any ideas ?
    What we need are EJB's without any timeout!

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

  • EJB Transaction-Timeout Effects

    Hi,
    We have a long running process, well, longer than the 60 seconds of the default transaction time-out set in the server.xml. I was going to lengthen it but thought I better ask as changing it to a larger amount of time might cause some effects that are undesired.
    So a couple of question:
    1) Why was it defaulted to 60 seconds, is there something unique about 60 seconds or is just a number to start with.
    2) What are the effects of making it larger (e.g. degraded performance, memory usage, connection pool?
    3) How does the transaction-timeout property affect the JDBC connection(s) that are contained within the scope of the transaction?
    4) Does the transaction timeout affect the time sql queries can take? Or is that the inactivity-timeout?
    I greatly appreciate any feedback I can get.
    Thanks,
    Donovan

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

  • Default EJB transaction timeout

    Within the weblogic-ejb-jar.xml it is possible to set:
    <transaction-descriptor>
    <trans-timeout-seconds>120</trans-timeout-seconds>
    </transaction-descriptor>
    which tells the container the maximum period of time an EJB method is allowed to run. Is there some default value that is used if this is not set? Or does leaving this tag out of the XML file completely give the EJB methods infinite time to return?

    "Ruben Ambrose" <[email protected]> wrote in message news:22852953.1100634354551.JavaMail.root@jserv5...
    Within the weblogic-ejb-jar.xml it is possible to set:
    <transaction-descriptor>
    <trans-timeout-seconds>120</trans-timeout-seconds>
    </transaction-descriptor>
    which tells the container the maximum period of time an EJB method is allowed to run. Is there some default value that is used ifthis is not set? Or does leaving this tag out of the XML file completely give the EJB methods infinite time to return?
    The default value is 30 seconds. This value can be changed via web ui console of by editing config.xml.
    <JTA Name="myServer" TimeoutSeconds="60"/>
    Also, even if the timeout is set in the DD, factual timeout is defined by initiator of the TX.
    Slava

  • Ejb Transaction Timeouts

    We have a weblogic cluster, we keep getting messages in the logs saying "Transaction timed out after 60 seconds". We have also noticed that if we shutdown one of the servers in the cluster then we do not get these messages in the logs.What could be the reason for this?
    Please advise.
    Anil

    Sorry for the delay:
    Here is the stack trace
    Error marking transaction for rollback: java.lang.IllegalStateException: Cannot mark the transaction for rollback. xid=23645:9de7ceb8422f21aa, status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 60 seconds Name=[EJB com.nextjet.enterprise.timing.timingmanager.TimingManagerBean.actionFired(flux.RemoteKeyFlowContext)],Xid=23645:9de7ceb8422f21aa(148367394),Status=Active,numRepliesOwedMe=1,numRepliesOwedOthers=0,seconds since begin=60,seconds left=60,activeThread=Thread[RUNNER: 33273648,5,main],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none,xar=weblogic.jdbc.jts.Connection@8d7ea8e),SCInfo[exms+enterprise1]=(state=active),SCInfo[exms+routing2]=(state=active),properties=({ISOLATION LEVEL=2, weblogic.transaction.name=[EJB com.nextjet.enterprise.timing.timingmanager.TimingManagerBean.actionFired(flux.RemoteKeyFlowContext)], weblogic.jdbc=t3://myserver.domain.com:3337}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=enterprise1+myserver.domain.com:3337+exms+t3+, Resources={})],CoordinatorURL=enterprise1+myserver.domain.com:3337+exms+t3+)]
    Server name: enterprise1
    Time: 07:05:00
    Date: 07/30/2004

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

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

  • Changing default transaction timeout for 5.1

              Hi
              Does someone know a way to change the default ejb transaction timeout for
              WL5.1?
              The default is 300 secs, which is a bit too long for me.
              I know I can change it in each deployment descriptor but it would be easier
              and quicker if I could just change the default :-)
              Thanks
              Nicolas
              

    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.

  • JTA timeout value doesn't take effect within stateful EJB

    Platform : weblogic10.3.5
    problem description: I have 2 ejbs: ejb1 is a stateful bean and the transaction is bean managed, the trans-timeout-seconds is set to 60; ejb2 is a stateless bean, transaction is container managed, transaction type is required, trans-timeout-seconds is 35. And the JTA timeout value set in weblogic console is 20.
    ejb1 invokes the ejb2's interface to access db, and this transaction should be committed since ejb2 is container managed transaction. Then ejb1 create userTransaction to access db. And I found the transaction will be timed out after 35 seconds, which is the trans-timeout-seconds of ejb2.
    Here is the sample code
    ejb1.method(){
         ejb2.method();
         try{
              Context ctx = new InitialContext();
              UserTransaction ut = (UserTransaction) ctx.lookup(USER_TRANSACTION_REF_NAME);
              ut.begin();
                   //do some operation
              ut.commit();
         }catch(Exception e){
                   try{
              ut.rollback();
                   }catch(Exception ee){
    Is timeout value of the user transaction created in ejb1 should be jta timeout 20? why the ejb2's trans-timeout-seconds affects the ejb1's usertransaction timeout value? does any body know the reason?
    Thanks

    A transaction timeout will not and cannot terminate user code as there
    is no Java API for doing so. If you wish the user code to timeout, try
    using the "setQueryTimeout()" method on the SQL statement. The WebLogic
    JTS will timeout the transaction using another thread and will prevent
    any JDBC activity associated with the global transaction from being
    commited.
    Sincerely,
    Charlie Therit
    Developer Relations Engineer
    BEA Support
    hjkuob wrote:
    "Dear Support,
    We encounter problems with transaction timeout and details as follows:
    A swing UI calls a session bean in which a DAO(Data Access Object) is invoked,
    In this DAO, it try to invoke a store procedure like following :
    dateSource = getTxDataSource();
    conn = (Connection)dataSource.getConnection();
    cstmt = conn.prepareCall("{call PK_AP_OO_CATCH_UP.P_AP_MAIN(?,?) }");
    cstmt.registerOutParameter(...........);
    cstmt.execute();
    When a irrevalent guy carelessly locked the table , the swing keep running for 5 hours and
    the transaction never throws exception ( both JTA and trans-timeout-seconds are set).
    I've also survey docments , however, we are not sure about the definition of Container-managed transactions
    and Bean-managed transactions. So there are two problems to be solved :
    1. How to solve the timeout problem as the sample code above for calling store procedures,
    and what kind of transctions it uses according to the definition ?
    2. If a normal sql statement is executed as follows , should we declare explicit transaction ( begin and commit) ? %

  • How to set the EJB timeout value??

    I made a Swing application connecting with EJB to provide some service. If I set the correct J2EE server IP, everything works fine. However, it will throw an Exception after some time, if I set an incorrect IP. I would like to ask if there is any means to set a timeout value for the Swing application that it throws an exception while it cannot connect to the server after the timeout value.

    Hi,
    Amount of time required to call an EJB on a remote server depends on, I would guess, multiple factors, like server performance, network speed, link quality, etc. I'm not sure if there is a direct way of telling the client-side code to wait for results for a limited amount of time, but in general blocking on the client side until the server results are available is not a good idea (at least not from the GUI perspective, since you would be locking the display). Either way, you could make all your EJB calls from a separate thread, and timeout that. This way your client code would have complete control of responsiveness of the server side.
    Just a thought.
    Mark

Maybe you are looking for