MDB Timeouts and transaction behavior

Hi, thanks in advance for any help with this.
We have a MDB where we have set the timeout to five minutes. In a particular case this timeout is being reached but even though the MDB times out the transaction and sends the message for redelivery the original transaction that was processing the message continues until something happens from an application standpoint to cause that original transaction to complete. This means that we have the same message processed twice under these circumstances.
I would have expected that if a transaction timed out that the transaction would have been terminated and therefore our processing would have stopped. Is there a way to force this behavior or do we have to put an alarm in our code and kill ourselves such that we never encounter the transaction time out?
Thanks,
Sue Shanabrook

I should have mentioned that we are using container managed transactions.

Similar Messages

  • Task Flow Transaction Behavior and AM Activation/Passivation

    Hi All,
    In my app, when I changed the transaction behavior from 'No Controller Transaction' to 'Use Existing Transaction If Possible', I started seeing the following type of AM Passivation snapshot is JDev log:
    <ADFLogger> <begin> Passivating Application Module
    <PCollManager> <resolveName> [3560] **PCollManager.resolveName** tabName=PS_TXN
    <DBTransactionImpl> <getInternalConnection> [3561] Getting a connection for internal use...
    <DBTransactionImpl> <getInternalConnection> [3562] Creating internal connection...
    <ADFLogger> <begin> Establish database connection
    <DBTransactionImpl> <establishNewConnection> [3563] Trying connection: DataSource='weblogic.jdbc.common.internal.RmiDataSource@4d0ca0'...
    <DBTransactionImpl> <establishNewConnection> [3564] Before getNativeJdbcConnection='weblogic.jdbc.wrapper.JTAConnection_weblogic_jdbc_wrapper_XAConnection_oracle_jdbc_driver_LogicalConnection
    <DBTransactionImpl> <establishNewConnection> [3565] After getNativeJdbcConnection='weblogic.jdbc.wrapper.JTAConnection_weblogic_jdbc_wrapper_XAConnection_oracle_jdbc_driver_LogicalConnection
    <ADFLogger> <addContextData> Establish database connection
    <ADFLogger> <end> Establish database connection
    <OraclePersistManager> <syncSequenceIncrementSize> [3566] **syncSequenceIncrementSize** altered sequence 'increment by' value to 50
    <ViewObjectImpl> <doPassivateSettings> [3567] DateTimeVO1 passivating with paramsChanged
    <Serializer> <passivate> [3568] <AM MomVer="0">
    <cd/>
    <TXN Def="1" New="0" Lok="2" tsi="0" pcid="40"/>
    <CONN/>
    <VO>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseRoutingMainVO" Name="BaseRoutingMainVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseRoutingDetailsVO" Name="BaseRoutingDetailsVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseParameterVO" Name="BaseParameterVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseErrorLookupVO" Name="BaseErrorLookupVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseCompDataHdrVO" Name="BaseCompDataHdrVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseCompDataDtlVO" Name="BaseCompDataDtlVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseDataReqValVO" Name="BaseDataReqValVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseRegistrationPointVO" Name="BaseRegistrationPointVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseTradingPrtnrInfoVO" Name="BaseTradingPrtnrInfoVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseTradingPrtnrVerCtrlVO" Name="BaseTradingPrtnrVerCtrlVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseNotificationVO" Name="BaseNotificationVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseTransactionDefVO" Name="BaseTransactionDefVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.BaseValidationTypeVO" Name="BaseValidationTypeVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.OrigTransDetailsVO" Name="OrigTransDetailsVO1"/>
    <VO sig="1315216374468" qf="0" ut="0" da="1" It="1" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.TradingPartnerBaseVO" Name="TradingPartnerBaseVO1">
    <rsq>
    <![CDATA[SELECT /*+ FIRST_ROWS */ * FROM (SELECT 'X' AS TRADING_PARTNER_ID FROM DUAL) QRSLT ]]>
    </rsq>
    <Key>
    <![CDATA[00010000000158]]>
    </Key>
    </VO>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.TransErrorVO" Name="TransErrorVO1"/>
    <VO sig="1315216374468" qf="0" ut="0" It="1" Sz="25" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.DateTimeVO" Name="DateTimeVO1">
    <exArgs count="1">
    <arg name="TimeZone">
    <![CDATA[GMT]]>
    </arg>
    </exArgs>
    <rsq>
    <![CDATA[SELECT /*+ FIRST_ROWS */ * FROM (SELECT CurrentTime FROM
    SELECT TO_CHAR(SYSDATE,'DD-MON-YYYY HH:MI AM') AS CurrentTime, 'GMT' AS TZ FROM DUAL
    UNION
    SELECT TO_CHAR(SYSDATE+5.5/24,'DD-MON-YYYY HH:MI AM') AS CurrentTime, 'IST' AS TZ FROM DUAL
    UNION
    SELECT TO_CHAR(SYSDATE-8/24,'DD-MON-YYYY HH:MI AM') AS CurrentTime, 'PST' AS TZ FROM DUAL
    UNION
    SELECT TO_CHAR(SYSDATE-6/24,'DD-MON-YYYY HH:MI AM') AS CurrentTime, 'CST' AS TZ FROM DUAL
    UNION
    SELECT TO_CHAR(SYSDATE-5/24,'DD-MON-YYYY HH:MI AM') AS CurrentTime, 'EST' AS TZ FROM DUAL
    WHERE TZ=:TimeZone) QRSLT ]]>
    </rsq>
    <Key>
    <![CDATA[0000000000010000013239013AC4]]>
    </Key>
    </VO>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.TransTrackingVO" Name="TransTrackingVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.TransDependencyVO" Name="TransDependencyVO1"/>
    <VO sig="1315216374468" qf="0" ut="0" da="1" It="1" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.TradingPartnerBaseVO" Name="TradingPartnerBaseVO2">
    <rsq>
    <![CDATA[SELECT /*+ FIRST_ROWS */ * FROM (SELECT 'X' AS TRADING_PARTNER_ID FROM DUAL) QRSLT ]]>
    </rsq>
    <Key>
    <![CDATA[00010000000158]]>
    </Key>
    </VO>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.ReceiverTransDetailsVO" Name="ReceiverTransDetailsVO1"/>
    <VO sig="1315216374468" qf="0" ut="0" da="1" It="1" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.TransIDBaseVO" Name="TransIDBaseVO1">
    <rsq>
    <![CDATA[SELECT /*+ FIRST_ROWS */ * FROM (select 1 AS transaction_record_id from DUAL) QRSLT ]]>
    </rsq>
    <Key>
    <![CDATA[000100000002C102]]>
    </Key>
    </VO>
    <VO sig="1315216374468" qf="0" ut="0" da="1" It="1" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.TransKeyBaseVO" Name="TransKeyBaseVO1">
    <rsq>
    <![CDATA[SELECT /*+ FIRST_ROWS */ * FROM (SELECT 'X' AS document_key FROM dual) QRSLT ]]>
    </rsq>
    <Key>
    <![CDATA[00010000000158]]>
    </Key>
    </VO>
    <VO sig="1315216374468" qf="0" ut="0" da="1" It="1" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.TransStatusBaseVO" Name="TransStatusBaseVO1">
    <rsq>
    <![CDATA[SELECT /*+ FIRST_ROWS */ * FROM (SELECT 'X' AS STATUS FROM DUAL) QRSLT ]]>
    </rsq>
    <Key>
    <![CDATA[00010000000158]]>
    </Key>
    </VO>
    <VO sig="1315216374468" qf="0" ut="0" da="1" It="1" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.ErrorTypeBaseVO" Name="ErrorTypeBaseVO1">
    <rsq>
    <![CDATA[SELECT /*+ FIRST_ROWS */ * FROM (SELECT 'X' AS ERROR_TYPE FROM DUAL) QRSLT ]]>
    </rsq>
    <Key>
    <![CDATA[00010000000158]]>
    </Key>
    </VO>
    <VO sig="1315216374468" qf="0" ut="0" da="1" It="1" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.DependencyBaseVO" Name="DependencyBaseVO1">
    <rsq>
    <![CDATA[SELECT /*+ FIRST_ROWS */ * FROM (SELECT 'X' AS DEPENDENCY FROM DUAL) QRSLT ]]>
    </rsq>
    <Key>
    <![CDATA[00010000000158]]>
    </Key>
    </VO>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.MasterTransDependencyVO" Name="MasterTransDependencyVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.TrackingVO" Name="TrackingVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.ErrorVO" Name="ErrorVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.DashboardTransErrorVO" Name="DashboardTransErrorVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.DashboardTransDependencyVO" Name="DashboardTransDependencyVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.DashboardTransPieVO" Name="DashboardTransPieVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.DashboardMasterTransBarVO" Name="DashboardMasterTransBarVO1"/>
    <VO sig="1315216374468" qf="0" ut="0" da="1" It="1" Sz="25" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.ReceiverTransStatusBaseVO" Name="ReceiverTransStatusBaseVO1">
    <rsq>
    <![CDATA[SELECT /*+ FIRST_ROWS */ * FROM (SELECT 'X' AS STATUS FROM DUAL) QRSLT ]]>
    </rsq>
    <Key>
    <![CDATA[00010000000158]]>
    </Key>
    </VO>
    <VO sig="1315216374468" qf="0" ut="0" da="1" It="1" Sz="25" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.ErrorStatusBaseVO" Name="ErrorStatusBaseVO1">
    <rsq>
    <![CDATA[SELECT 'X' AS ERROR_STATUS FROM DUAL]]>
    </rsq>
    <Key>
    <![CDATA[00010000000158]]>
    </Key>
    </VO>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.HeaderVO" Name="HeaderVO1"/>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.TradingPartnerBaseVO" Name="TradingPartnerBaseVO3"/>
    <VO sig="1315216374468" qf="0" ut="0" da="1" It="1" Sz="25" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.HeaderStatusBaseVO" Name="HeaderStatusBaseVO1">
    <rsq>
    <![CDATA[SELECT 'X' AS STATUS FROM DUAL]]>
    </rsq>
    <Key>
    <![CDATA[00010000000158]]>
    </Key>
    </VO>
    <VO sig="1315216374468" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.TradingPartnerBaseVO" Name="TradingPartnerBaseVO4"/>
    <VO sig="1315216374468" qf="0" ut="0" da="1" It="1" Sz="25" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.HeaderSourceFileNameBaseVO" Name="HeaderSourceFileNameBaseVO1">
    <rsq>
    <![CDATA[SELECT 'X' AS SOURCE_FILE_NAME FROM DUAL]]>
    </rsq>
    <Key>
    <![CDATA[00010000000158]]>
    </Key>
    </VO>
    <VO sig="1315216374468" qf="0" ut="0" da="1" It="1" Sz="25" St="0" im="1" Ex="1" Def="com.emerson.eth.adf.model.view.DependencyStatusBaseVO" Name="DependencyStatusBaseVO1">
    <rsq>
    <![CDATA[SELECT 'X' AS DEPENDENCY_STATUS FROM DUAL]]>
    </rsq>
    <Key>
    <![CDATA[00010000000158]]>
    </Key>
    </VO>
    <VO sig="1315216382156" vok="20" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.HeaderSourceFileNameLOVVO" Name="_LOCAL_VIEW_USAGE_com_emerson_eth_adf_model_view_HeaderSourceFileNameBaseVO_HeaderSourceFileNameLOVVO1"/>
    <VO sig="1315216384812" vok="20" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.ReceiverTransStatusLOVVO" Name="_LOCAL_VIEW_USAGE_com_emerson_eth_adf_model_view_ReceiverTransStatusBaseVO_ReceiverTransStatusLOVVO1"/>
    <VO sig="1315216385921" vok="20" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.HeaderStatusLOVVO" Name="_LOCAL_VIEW_USAGE_com_emerson_eth_adf_model_view_HeaderStatusBaseVO_HeaderStatusLOVVO1"/>
    <VO sig="1315216387093" vok="20" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.ErrorStatusLOVVO" Name="_LOCAL_VIEW_USAGE_com_emerson_eth_adf_model_view_ErrorStatusBaseVO_ErrorStatusLOVVO1"/>
    <VO sig="1315216388171" vok="20" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.DependencyStatusLOVVO" Name="_LOCAL_VIEW_USAGE_com_emerson_eth_adf_model_view_DependencyStatusBaseVO_DependencyStatusLOVVO1"/>
    <VO sig="1315216393937" vok="20" qf="0" RS="0" Def="com.emerson.eth.adf.model.view.TransIDLovVO" Name="_LOCAL_VIEW_USAGE_com_emerson_eth_adf_model_view_TransIDBaseVO_TransIDLovVO1">
    <VC n="__ImplicitViewCriteria__" d="true" c="0" bv="true" m="1" j="false">
    <vcp>
    <p n="showInList" v="true"/>
    <p n="displayName" v="Implicit Search"/>
    </vcp>
    <Row n="vcrow1" uc="0" cj="0">
    <a i="0">
    <i o="=" cj="1" uc="0" r="2" vb="false" g="true" e="false" re="false">
    <iv i="0" b="0" sf="0"/>
    </i>
    </a>
    <a i="1">
    <i o="STARTSWITH" cj="1" uc="0" r="2" vb="false" g="true" e="false" re="false">
    <iv i="0" b="0" sf="0"/>
    </i>
    </a>
    </Row>
    </VC>
    <VC n="LOV_TransactionRecordId__lov__filterlist__vcr___" d="true" c="0" bv="true" m="3" j="false">
    <Row n="LOV_TransactionRecordId__lov__filterlist__vcr___" uc="0" cj="0">
    <a i="0">
    <i o="=" cj="1" uc="0" r="2" vb="false" g="true" e="false" re="false">
    <iv i="0" b="0" sf="0">
    <![CDATA[40532]]>
    </iv>
    </i>
    </a>
    </Row>
    </VC>
    </VO>
    </VO>
    </AM>
    <OraclePersistManager> <insert> [3569] **insert** id=1, parid=-1, collid=65951, keyArr.len=-1, cont.len=10035
    <OraclePersistManager> <insert> [3570] stmt: insert into "PS_TXN" values (:1, :2, :3, :4, sysdate)
    <OraclePersistManager> <commit> [3571] **commit** #pending ops=1
    <ADFLogger> <end> Passivating Application Module
    My question is does AM gets passivated on each request. This snapshot is not visible when Transaction behavior is set to 'No Controller Transaction'.
    This type is snapshot is usually visible in case of 'No Controller Transaction', when AM Pooling is off or if AM Pooling is enabled then Failover support is on.
    Is this OK for this snapshot to appear in JDev log or am I missing something?

    this might be helpful, can u chk
    The subtle use of task flow "No Controller Transaction" behavior
    http://blogs.oracle.com/raghuyadav/entry/adf_taskflow_transaction_manag
    http://andrejusb.blogspot.com/2010/01/demystifying-adf-bc-passivation-and.html

  • I have a workflow transaction which got timeout and escalated to the next level. The comments in the approver's notes are just changed by the system in doing so.  For eg: "Moving John under Michael" gets changed into "Moving+John+under+Michael" during the

    I have a workflow transaction which got timeout and escalated to the next level. The comments in the approver's notes are just changed by the system in doing so.
    For eg: "Moving John under Michael" gets changed into "Moving+John+under+Michael" during the timeout/reminder notification. Any idea ?
    -Thanks,
    Arun

    I have recently started having this problem in PSE8. The Adobe workaround
    did work, but I don't fancy having to re register each time I use it.
    What I have discovered is that it's nothing to do with the image metadata as it occurs before any image is opened.
    It SEEMS to only occur if you use file/open with to open an image in the editor - IE start PSE with that command.
    If you close elements down, and start it using programs/PSE/Elements (or your desktop shortcut) - the panorama feature magically works.
    Each time I've opened the editor 'automatically' using image/open with, it seems to create the problem.
    Hope this helps

  • MDBs and Transactions.

    Ok,
    I am bit confused with how exactly MDBs work with Transactions.
    For example,
    suppose we have a simple standalone java message producer which sends a message to a Queue. A MDB's onMessage() picks it up.
    Let's say the MDB makes some updates to the database and then invokes a method on a stateless session bean which also updates a database.
    By default the transaction attribute of the MDB and stateless session bean would be REQUIRED.
    If the stateless session bean database update fails, I presume the MDB's database updates also get rolled back.
    But, does the message get rolled back? If not when would the message be rolled back?
    Does it make any difference if the MDB is a topic or a queue? Does it make any difference if the message producer is a standalone client or
    a stateless session bean with it's own transactional behaviour?
    Any help appreciated.
    Thanks.

    The general principle is: if you have a MDB which consumes a message in a transaction, and that transaction is rolled back, then the message is "rolled back". This means that it is put back on the queue or topic. It will then be delivered to the MDB again.
    If your MDB calls a session bean then the two can share the same global transaction as you suggest.
    Note however that the transaction which consumes the message is completely separate from any transaction which placed the message on the queue in the first place. JMS completely decouples the two steps. Once the message is added to the queue the producer is irrelevant.
    Nigel

  • EjbTimeout() and transactions

    Hello all-
    First time poster here, long question, please be gentle....
    We are running a weblogic 10.0 MP1 install here, and our application employs the EJB3 timer service to schedule processing.
    What we need to happen is for the ejbTimeout() method to be called periodically (this is working fine) but not start a transaction when it is invoked. (this is not)
    The processing that our ejbTimeout() method does can be very time consuming (talking to external, 3rd party services) so we do not want a weblogic transaction active while this is taking place. If a transaction is active, it will frequently time out. The idea is that the ejbTimeout() invoke other stateless session bean method(s) that begin a transaction to record the results of the conversation after the long delay is done.
    (Note that I am aware that I could increase the allowable timeout for transactions, but this seems like a poor solution, correct me if I am wrong)
    I have the ejbTimeout() method annotated as TransactionAttributeType.NOT_SUPPORTED. What I would expect to see is that because of this, the ejbTimeout method can linger as long as it wants before calling a TransactionAttributeType.REQUIRES_NEW method to start a transaction to record the results. However I see errors like:
    javax.ejb.EJBTransactionRolledbackException: EJB Exception: : javax.transaction.TransactionRolledbackException: EJB Exception: : weblogic.transaction.internal.TimedOutException: Transaction timed out after 31 seconds
    <many lines omitted>
    at com.......RetrieveEmailBusiness.retrieveEmail(RetrieveEmailBusiness.java:82)
    at com......EmailRetrievalSchedulerBean.ejbTimeout(EmailRetrievalSchedulerBean.java:96)
    Suggesting that there WAS a transaction active while ejbTimeout() was running. How can I prevent ejbTimeout() from being called in the context of a transaction? Do I not understand something about the semantics of NOT_SUPPORTED?
    Another side question: The documentation I have says that a NOT_SUPPORTED method when called will "suspend" any transaction that is active for the calling method, and not participate in it. By suspend, does that include stopping the clock? In other words, if the transaction timeout is 30 seconds, and the calling method is 5 seconds into the transaction when it calls the NOT_SUPPORTED method, and that method takes 26 seconds to run, will that cause the outer transaction to roll back when the calling method exits?
    Thank you all in advance.

    At the moment (Production 1.0.4.3 and Beta 9.0.0.0.0) the XSQL action handler implementation for <xsql:insert-request> does an explicit commit.
    I've filed a bug (#1727863) to get a similar commit="yes|no" attribute added to the <xsql:insert-request>, just like there is now one supported on <xsql:dml>
    In the interim, you'd need to write a custom action handler that uses the XML SQL Utility's OracleXMLSave class to have the behavior you want.

  • Re: What is the relationship between the JTA Server Timeout and

    Two things. The transaction timeout is set when the transaction starts. When are you setting the timeout, and where are you starting the transaction?
              There is a bug in 6.0 SP1. The EJB subsystem always sets the transaction timeout. If you don't specify anything in your descriptor. It sets the timeout to 30 seconds. However, if you
              change the JTA default to 60 seconds, the EJB container won't see this change. This is fixed in our next minor release.
              -- Rob
              Tom Gerber wrote:
              > What is the relationship between the JTA Server Timeout and an EJB's <transcation-timeout-seconds> parameter?
              >
              > Does the EJB's timeout have to be >= the servers to take effect?
              >
              > We tried setting the timeout in the XML file to 60 seconds but the transaction still timed out after 30 seconds or so which makes me believe the server timeout overrides the EJB's timeout.
              >
              > Is this correct behavior?
              >
              > We are on WL 6.0 sp1
              >
              > Thanks
              >
              > Tom
              

    Sorry, you cannot query for known bugs yet.
              Work is in progress :)
              Kumar
              Tom Gerber wrote:
              > Is there a place on the WebSupport site for WebLogic that I can query
              > for know issues for WL 6 sp1?
              >
              > I tried the Find Solutions but didn't find much.
              >
              > Thanks
              >
              > Rob Woollen wrote:
              >
              > > Two things. The transaction timeout is set when the transaction starts. When are you setting the timeout, and where are you starting the transaction?
              > >
              > > There is a bug in 6.0 SP1. The EJB subsystem always sets the transaction timeout. If you don't specify anything in your descriptor. It sets the timeout to 30 seconds. However, if you
              > > change the JTA default to 60 seconds, the EJB container won't see this change. This is fixed in our next minor release.
              > >
              > > -- Rob
              > >
              > > Tom Gerber wrote:
              > >
              > >> What is the relationship between the JTA Server Timeout and an EJB's <transcation-timeout-seconds> parameter?
              > >>
              > >> Does the EJB's timeout have to be >= the servers to take effect?
              > >>
              > >> We tried setting the timeout in the XML file to 60 seconds but the transaction still timed out after 30 seconds or so which makes me believe the server timeout overrides the EJB's timeout.
              > >>
              > >> Is this correct behavior?
              > >>
              > >> We are on WL 6.0 sp1
              > >>
              > >> Thanks
              > >>
              > >> Tom
              > >
              

  • Session timeout and custom sso

    Hi,
    can anyone tell me how the session and idle timeout feature in Apex exactly works?
    I built several applications in a workspace and do a sso authorization by setting a common cookie name. In addition to that i set the values for session length and idle timeout and assumed that the session length would be synchronized over all applications. But this doesn't seem to work. For instance, i set the idle timeout to 10 minutes in all applications and now i work for 15 minutes continously in application A and after that i switch over to application B (using the same session id!), the session is already expired in B.
    Is this behavior correct? And, if yes, how can i set up a synchronization over all applications?
    Jens

    Anyone?

  • The subtle use of task flow "No Controller Transaction" behavior

    I'm trying to tease out some subtle points about the Task Flow transactional behavior option "<No Controller Transaction>".
    OTN members familiar with task flows in JDev 11g and on wards would know that task flows support options for transactions and data control scope. Some scenarios based on these options:
    a) When we pick options such as "Use Existing Transaction" and shared data control scope, the called Bounded Task Flow (BTF) will join the Data Control Frame of its caller. A commit by the child does essentially nothing, a rollback of the child rolls any data changes back to when the child BTF was called (i.e. an implicit save point), while a commit of the parent commits any changes in both the child and parent, and a rollback of a parent loses changes to the child and parent.
    A key point to realize about this scenario is the shared data control scope gives both the caller and called BTF the possibility to share a db connection from the connection pool. However this is dependent on the configuration of the underlying services layer. If ADF BC Application Modules (AMs) are used, and they use separate JNDI datasources this wont happen.
    b) When we pick options such as "Always Begin New Transaction" and isolated data control scope, the called BTF essentially has its own Data Control Frame separate to that of the caller. A commit or rollback in either the parent/caller or child/called BTF are essentially isolated, or in other words separate transactions.
    Similar to the last point but the exact opposite, regardless how the underlying business services are configured, even if ADF BC AMs are used with the same JNDI data source, essentially separate database connections will be taken out assisting the isolated transactional behavior with the database.
    This brings me back to my question, of the subtle behavior of the <No Controller Transaction> option. Section 16.4.1 of the Fusion Guide (http://download.oracle.com/docs/cd/E17904_01/web.1111/b31974/taskflows_parameters.htm#CIHIDJBJ) says that when this option is set that "A new data control frame is created without an open transaction." So you could argue this mode is the same as isolated data control scope, and by implication, separate connections will be taken out by the caller/called BTF. Is this correct?
    Doesn't this in turn have implications about database read consistency? If we have one BTF participating in a transaction with the database, reading then writing data, and a separate BTF with the <No Controller Transaction> option set, it's possible it wont see the data of the first BTF unless committed before the No Controller Transaction BTF is called and queries it's own dataset correct?
    An alternative question which takes a different point of view, is why would you ever want this option, don't the other options cover all the scenarios you could possibly want to use a BTF?
    Finally as a separate question based around the same option, presumably an attempt to commit/rollback the Data Control Frame of the associated No Controller Transaction BTF will fail. However what happens if the said BTF attempts to call the Data Control's (not the Data Control Frame's) commit & rollback options? Presumably this will succeed?
    Your thoughts and assistance appreciated.
    Regards,
    CM.

    For other readers this reply is a continuation of this thread and another thread: Re: Clarification?: Frank & Lynn's book - task flow "shared" data control scope
    Hi Frank
    Thanks for your reply. Okay I get the idea that were setting the ADFc options here, that can be overridden by the implementation of data control, and in my specific case that's the ADF BC AM implementation. I've always known that, but the issue became complicated because it didn't make sense what "No Controller Transaction" actually did and when you should use it, and in turn data control frames and their implementation aren't well documented.
    I think a key point from your summation is that "No Controller Transaction" in context of ADF BC, with either data control scope option selected, is effectively (as far as we can tell) already covered by the other options. So if our understanding is correct, the recommendation for ADF BC programmers is I think, don't use this option as future programmers/maintainers wont understand the subtlety.
    However as you say for users of other data controls, such as those using web services, then it makes sense and possibly should be the only option?
    Also regarding your code harvest pg 14 entry on task flow transactions: http://www.oracle.com/technetwork/developer-tools/adf/learnmore/march2011-otn-harvest-351896.pdf
    ....and the following quote in context of setting the transaction option to Begin New Transaction:
    >
    When a bounded task flow creates a new transaction, does it also mean it creates a new database connection? No.
    >
    ....I think you need to be a little more careful in this answer, as again it depends on the underlying data control implementation as you point out in this thread. In considering ADF BC, this is correct if you assume only one root AM. However if the BTFs have separate root AMs, this should result in 2 connections and transactions..... well at least I assume it does, though I wonder what will happen if both AMs share the same JNDI data source.... is the framework smart enough to join the connections/transactions in this case?
    Also in one of your other code harvests (apologies I can't find which one at the moment) you point out sharing data control scopes is only possible if the BTF data controls have the same name. In context of an ADF BC application, with only one root AM used by multiple BTFs, this of course would be the case. Yet, the obvious implication to your summary of transaction outcomes in this thread, if the developers for whatever reason change the DC name across DataBindings.cpx files sourced from ADF Libraries containing the BTFs, then no, it wont.
    Overall the number of variables in this gets really complicated, creating multiple dimensions to the matrix.
    Going to your last point, how can the documentation be improved? I think as you say the documentation is right in context of the options for ADFc, but, as the same documentation is included in the Fusion Dev Guide which assumes ADF BC is being used, then it isn't clear enough and can be misleading. It would seem to me, that depending on the underlying data control technology used, then there needs to be documentation that talks about the effect of ADFc task flow behavior options in the context of each technology. And God knows how you describe a scenario where BTFs use DCs that span technologies.
    From context of ADF BC, one thing that I've found hard in analyzing all of this is there doesn't seem to be an easy way from the middletier to check how many connections are being taken out from a data source. The FMW Control unfortunately when sampling db connections taken out from a JNDI data source pool, doesn't sample quickly enough to see how many were consumed. Are you aware of some easy method to check the number of the db connections opened/closed?
    Finally in considering an Unbounded Task Flow as separate to BTFs, do you have any conclusions about how it participates in the transactions? From what I can determine the UTF lies in it's own data control frame, and is effectively isolated from the BTF transactions, unless, the BTF calls commit/rollback at the ADF BC data control level (as separate to commit/rollback at the data control frame level), and the data control is used both by the UTF and BTF.
    As always thanks for your time and assistance.
    CM.

  • Weblogic: problem with JMS foreign server and Transaction

    Hello everyone,
    I am working with an enterprise application with Web Application Server Logic 10.3. L 'application uses the following components:
    1) MDB 2.0
    2) FOREIGN JMS SERVER -> WebSpereMQ
    3) EJB SESSION
    L 'MDB calls the session bean which uses in its ejb-jar.xml using a Wrapper for JMS QueueConnectionFactory with res-ref:
    <resource- ref>
    <res-ref-name> jms / iss / QCFIXP </ res-ref-name>
    <res-auth> Container </ res-auth>
    <res-sharing -scope> Shareable </ res-sharing-scope>
    <resource- ref>
    The MDB is CMT
    <transaction-type> Container </ transaction-type>
    while the session bean is BMT
    <transaction-type> Bean </ transaction-type>
    to call the QCFIXP in its transaction.
    The QCFIXP ii an XA resource
    When there is a rollback operation in SessionBean also in 'MDB
    There 'an operation setRollbackOnly:
    getMessageDrivenContext (). setRollbackOnly ();
    After this operation on the MDB I do a JNDI look up the QueueConnectionFactory but sending the message on a queue I get the following exception:
    javax.jms.JMSException: [JMSPool: 169809] An error occurred while registering the JMS connection with JTA:
    But if not using the "wrapper jms" in the session bean I did not take any exception and the application don' t have any error.
    My doubt is :
    Why if I use the JMS wrapper I get an error javax.jms.JMSException: [JMSPool: 169809] An error occurred while registering the JMS connection with JTA?
    Thanks in advance.
    Michele
    Edited by: user3501731 on 11-mag-2011 3.16

    Hi Tom,
    Thanks very much for your responses and careful analysis you've done.
    Following the source code of the MDB where error occurs.
    Marked In bold the line where the exception is thrown.
         public void onMessage(Message msg) {
    //          Utility.logger(AP.DEBUG, "Partito MDB 2");
              processa(msg);
              protected void processa(Message msg) {
              Utility.logger(
                   AP.DEBUG,
                   "IXPReceiverMDB7.processa(Message msg) partito");
              try {
                   long start = System.currentTimeMillis();
    /*               Utility.logger(
                        AP.DEBUG,
                        "IXPReceiverMDB.processa(Message msg) effettuo lookup");*/
                   ejb = myEjbLocalHome.create();
                   // individuo l'identificativo del messaggio in ricezione
                   String msgid = msg.getJMSMessageID();
                   Utility.logger(
                        AP.DEBUG,
                        "IXPReceiverMDB7.processa(Message msg) elaboro messaggio:"
                             + msgid);
                   String charset = msg.getStringProperty("JMS_IBM_Character_Set");
                   Utility.logger(
                        AP.DEBUG,
                        "IXPReceiverMDB7.processa Charset:" + charset );
                   // invoco il processo di ricezione
                   boolean commitRequested = ejb.processa(ctlReq, encoding, msg);
                   // il valore di ritorno del processo di ricezione identifica o meno
                   // la necessita' di effettuare il rollback dell'intero processo
                   if (!commitRequested) {
                        getMessageDrivenContext().setRollbackOnly();
                   if (ctlReq) {
                        Utility.logger(
                             AP.INFO,
                             "IXPReceiverMDB7.processa(Message msg) spedisco il messaggio pilota del 'cleaning' con JMSCorrelationID = '"
                                  + msgid
                                  + "'");
                        msg.setJMSCorrelationID(msgid);
                        // Viene creata la QueueConnection
                        QueueConnectionFactory factory =
                             JmsFactoryDispenser.getSingleton().getFactory();
                        QueueConnection connection = factory.createQueueConnection();
                        // Viene ottenuta la 'session'
                        QueueSession session =
                             connection.createQueueSession(
                                  false,
                                  Session.AUTO_ACKNOWLEDGE);
                        // spedisco il messaggio sulla coda abbinata al processo di 'cleaning'
                        // della coda di controllo
                        IXPMessageManager msgManager = new IXPMessageManager(session);
                        msgManager.spedisci(msg, AP.PILOTQUEUE, "J", AP.STD_MESSAGE);                    session.close();
                        connection.close();
                   long end = System.currentTimeMillis();
                   Long durata = new Long (end - start);
                   Utility.logger(
                        AP.INFO,
                        "IXPReceiverMDB7 Tempo totale elaborazione messaggio: " +
                        msgid + " " +
                        durata.toString() + " mill" );
                   Utility.logger(
                        AP.DEBUG,
                        "IXPReceiverMDB7.processa(Message msg) terminato");
              } catch (Throwable e) {
                   getMessageDrivenContext().setRollbackOnly();
                   try {
                        Utility.myExceptionHandler(
                             "E",
                             "1",
                             "4028",
                             "IXPReceiverMDB.onMessage()",
                             e);
                   } catch (Throwable ex) {
                        ex.printStackTrace();
    Thanks in advance.
    Edited by: serpichetto on 16-mag-2011 1.24

  • Current server is the coordinator and transaction is not found

    Hi,
    We're using Weblogic 8.1 SP3. We have a single weblogic domain and 2 clusters in it. EAR1 is deployed in cluster 1 and EAR2 is deployed in cluster 2. EAR2 is compiled and created using j2ee.jar and not weblogic.jar.
    We have a MessageDrivenBean which is CMT / Required in EAR1 calls a BMT Stateless Session Bean in EAR2.
    A new transaction is begun in the BMT SB method and commit or rollback is called based on exception. A RuntimeException is thrown back to the MDB in case the transaction is rolled back in Bean Managed SB.
    Sometimes from the Bean Managed SB the following exception is thrown:
    javax.transaction.TransactionRolledbackException: Current server is the coordinator and transaction is not found. It was probably rolled back and forgotten already.
         at weblogic.rjvm.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:108)
         at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:284)
         at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:244)
         at com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskBean_1gq9kv_EOImpl_813_WLStub.handleRequest(Unknown Source)
         at com.oakgrovesystems.reactor.requests.ReactorRequest.send(ReactorRequest.java:212)
         at com.oakgrovesystems.reactor.client.EJBReactorProxy.sendRequest(EJBReactorProxy.java:44)
         at com.oakgrovesystems.reactor.client.AbstractReactorProxy.handleRequest(AbstractReactorProxy.java:52)
         at sun.reflect.GeneratedMethodAccessor153.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:324)
         at tavant.bpm.client.proxy.DynamicFailoverReactorProxy.invoke(DynamicFailoverReactorProxy.java:84)
         at $Proxy11.handleRequest(Unknown Source)
         at tavant.bpm.client.ProcessHome.handleRequest(ProcessHome.java:298)
         at tavant.bpm.client.ProcessHome.startProcess(ProcessHome.java:87)
         at tavant.bpm.client.processor.CreateWorkflowInstance.startProcess(CreateWorkflowInstance.java:70)
         at tavant.bpm.client.processor.CreateWorkflowInstance.invoke(CreateWorkflowInstance.java:51)
         at tavant.bpm.ejb.AsynchronousProcessorMessageBean.onMessage(AsynchronousProcessorMessageBean.java:58)
         at weblogic.ejb20.internal.MDListener.execute(MDListener.java:370)
         at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:262)
         at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2678)
         at weblogic.jms.client.JMSSession.execute(JMSSession.java:2598)
         at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
         at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
    This is not consistently reproducible though it happens when server is heavily loaded. When this exception occurs, the transaction in the BMT Session Bean is actually getting committed! The message gets redelivered from the MDB.
    What could be the problem?
    Regards
    Sandhya

    I'm seeing a similiar problem on our servers recently and thought I would add my problem as well. We are using Weblogic 8.1; don't know which SP is in production. We have an EAR file with an SB EJB that puts messages in a queue. The EAR is deployed in a cluster along with the queues. The errors below occurred in 3 of the 4 WLS instances in our cluster. This happened during a peak period and lasted for several seconds in Production.
    ###<Jul 1, 2005 11:18:12 AM EDT> <Warning> <RMI> <exsdxtxeax1x.prod.xxxx.xxx> <ems-04> <ExecuteThread: '12' for queue: 'web
    logic.kernel.Default'> <<WLS Kernel>> <> <BEA-080006> <Failed to associate the transaction context with the response while marshall
    ing an exception to the client:
    javax.transaction.TransactionRolledbackException: Current server is the coordinator and transaction is not found. It was probably
    rolled back and forgotten already..
    javax.transaction.TransactionRolledbackException: Current server is the coordinator and transaction is not found. It was probably
    rolled back and forgotten already.
    at weblogic.transaction.internal.TransactionManagerImpl.sendResponse(Ljava.lang.Object;)Ljava.lang.Object;(TransactionManag
    erImpl.java:1438)
    at weblogic.rmi.internal.BasicServerRef.associateTxContext(Lweblogic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.OutboundRespo
    nse;)V(BasicServerRef.java:490)
    at weblogic.rmi.internal.BasicServerRef.postInvoke(Lweblogic.rmi.extensions.server.RuntimeMethodDescriptor;Lweblogic.rmi.sp
    i.InboundRequest;Lweblogic.rmi.spi.OutboundResponse;Ljava.lang.Throwable;)V(Optimized Method)
    at weblogic.rmi.internal.BasicServerRef.handleRequest(Lweblogic.rmi.spi.InboundRequest;)V(Optimized Method)
    at weblogic.rmi.internal.BasicExecuteRequest.execute(Lweblogic.kernel.ExecuteThread;)V(Optimized Method)
    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)
    >

  • SDO Service Data Objects transaction behavior in BPEL question

    I was led to believe (this is taught in the SOA BCA class) that if we create, modify, or delete an SDO then the changes are committed at the end of the scope activity in the BPEL process and rolled back if there is an uncaught fault in the scope.
    I have faound that this is not what I am seeing. When modifying using an assign then the update is performed at the end of the assign, create and remove is also immediate. I have seen that if an assign has two copies and the first one succeeds and the second fails then both are rolled back.
    What is the correct behavior or is there a setting that controls the transaction behavior?
    Thanks ptlx

    I was led to believe (this is taught in the SOA BCA class) that if we create, modify, or delete an SDO then the changes are committed at the end of the scope activity in the BPEL process and rolled back if there is an uncaught fault in the scope.
    I have faound that this is not what I am seeing. When modifying using an assign then the update is performed at the end of the assign, create and remove is also immediate. I have seen that if an assign has two copies and the first one succeeds and the second fails then both are rolled back.
    What is the correct behavior or is there a setting that controls the transaction behavior?
    Thanks ptlx

  • Connection failover and transaction failover

    Connection failover and transaction failover
    I need to know more about a behavior in a RAC cluster. When a node goes down that is executing one of my transaction through JDBC , does the connection and transaction failover to a new node without me needing to restart tran or reconnect ?
    Please provide some insight
    Thanks

    Transactions are NOT automatically rolled back. The application must do this otherwise the session will get disconnected.
    If you code TAF, all sessions will failover to the backup connection. You can specify that select statements are automatically re-executed after the failover. Insert/update/delete transactions must be explicitly rolled back and resubmitted by the application.
    IF you are using an ORacle Connection pool, the connection pool will automatically cleanup connections to the failed instance, abort inflight transactions. The application will either retry or it will propagate the error to the end user.
    See the whitepaper on the OTN RAC page (otn.oracle.com/rac) Workload Management with Oracle RAC for more information.

  • MDB container managed transaction demarcation not working in wls 6.1 beta

    I have an MDB which sends the messages it receives onto another JMS
              destination within the onMessage method. These messages are not sent to
              the JMS destination unless I explicitly use a transacted session for the
              destination and subsequently commit the session. If I set the transacted
              parameter to Session as false the messages are sent. If I set the
              transacted parameter to true the messages will only be output if the
              session is committed. This is the standard behaviour for a JMS session
              but this is not the correct behaviour for an MDB running with
              container-managed transaction demarcation.
              For a start the transacted parameter to session should be ignored when
              run in the context of a container transaction and the commit method
              should thrown an exception as it is not allowed within the context of a
              container transaction.
              This is the MDB code and the deployment descriptor: -
              public class MessageBean implements MessageDrivenBean, MessageListener
              private String topicName = null;
              private TopicConnectionFactory topicConnectionFactory = null;
              private TopicConnection topicConnection = null;
              private TopicSession topicSession = null;
              private Topic topic = null;
              private TopicPublisher topicPublisher = null;
              private TextMessage textMessage=null;
              private transient MessageDrivenContext messageDrivenContext = null;
              private Context jndiContext;
              public final static String
              JMS_FACTORY="weblogic.examples.jms.TopicConnectionFactory";
              public final static String
              TOPIC="weblogic.examples.jms.exampleTopic";
              public MessageBean()
              public void setMessageDrivenContext(MessageDrivenContext
              messageDrivenContext)
              this.messageDrivenContext = messageDrivenContext;
              public void ejbCreate()
              public void onMessage(Message inMessage)
              try
              jndiContext = new InitialContext();
              topicConnectionFactory =
              (TopicConnectionFactory)jndiContext.lookup(JMS_FACTORY);
              topic = (Topic) jndiContext.lookup(TOPIC);
              topicConnection =
              topicConnectionFactory.createTopicConnection();
              topicConnection.start();
              // The transacted parameter should be ignored in the context of a
              container tx
              topicSession = topicConnection.createTopicSession(true,
              Session.AUTO_ACKNOWLEDGE);
              topicPublisher = topicSession.createPublisher(topic);
              textMessage = (TextMessage)inMessage;
              topicPublisher.publish(inMessage);
              // this is illegal in a container transaction
              topicSession.commit();
              topicConnection.close();
              catch (JMSException je)
              throw new EJBException(je);
              catch (NamingException ne)
              throw new EJBException(ne);
              public void ejbRemove()
              <?xml version="1.0" encoding="UTF-8"?>
              <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
              JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
              <ejb-jar>
              <enterprise-beans>
              <message-driven>
              <display-name>MessageBean</display-name>
              <ejb-name>MessageBean</ejb-name>
              <ejb-class>MessageBean</ejb-class>
              <transaction-type>Container</transaction-type>
              <message-driven-destination>
              <destination-type>javax.jms.Queue</destination-type>
              </message-driven-destination>
              <security-identity>
              <description></description>
              <run-as>
              <description></description>
              <role-name></role-name>
              </run-as>
              </security-identity>
              </message-driven>
              </enterprise-beans>
              <assembly-descriptor>
              <container-transaction>
              <method>
              <ejb-name>MessageBean</ejb-name>
              <method-name>*</method-name>
              </method>
              <trans-attribute>Required</trans-attribute>
              </container-transaction>
              </assembly-descriptor>
              </ejb-jar>
              

    Please see the response in the EJB newsgroup.
              Also, could you kindly only post to a single newsgroup?
              Thanks.
              "Jimmy Johns" <[email protected]> wrote in message
              news:[email protected]...
              > I have an MDB which sends the messages it receives onto another JMS
              > destination within the onMessage method. These messages are not sent to
              > the JMS destination unless I explicitly use a transacted session for the
              >
              > destination and subsequently commit the session. If I set the transacted
              >
              > parameter to Session as false the messages are sent. If I set the
              > transacted parameter to true the messages will only be output if the
              > session is committed. This is the standard behaviour for a JMS session
              > but this is not the correct behaviour for an MDB running with
              > container-managed transaction demarcation.
              >
              > For a start the transacted parameter to session should be ignored when
              > run in the context of a container transaction and the commit method
              > should thrown an exception as it is not allowed within the context of a
              > container transaction.
              >
              > This is the MDB code and the deployment descriptor: -
              >
              > public class MessageBean implements MessageDrivenBean, MessageListener
              > {
              > private String topicName = null;
              > private TopicConnectionFactory topicConnectionFactory = null;
              > private TopicConnection topicConnection = null;
              > private TopicSession topicSession = null;
              > private Topic topic = null;
              > private TopicPublisher topicPublisher = null;
              > private TextMessage textMessage=null;
              > private transient MessageDrivenContext messageDrivenContext = null;
              >
              > private Context jndiContext;
              >
              > public final static String
              > JMS_FACTORY="weblogic.examples.jms.TopicConnectionFactory";
              > public final static String
              > TOPIC="weblogic.examples.jms.exampleTopic";
              >
              > public MessageBean()
              > {
              > }
              >
              > public void setMessageDrivenContext(MessageDrivenContext
              > messageDrivenContext)
              > {
              > this.messageDrivenContext = messageDrivenContext;
              > }
              >
              > public void ejbCreate()
              > {
              > }
              >
              > public void onMessage(Message inMessage)
              > {
              > try
              > {
              > jndiContext = new InitialContext();
              > topicConnectionFactory =
              > (TopicConnectionFactory)jndiContext.lookup(JMS_FACTORY);
              > topic = (Topic) jndiContext.lookup(TOPIC);
              > topicConnection =
              > topicConnectionFactory.createTopicConnection();
              > topicConnection.start();
              > // The transacted parameter should be ignored in the context of a
              > container tx
              > topicSession = topicConnection.createTopicSession(true,
              > Session.AUTO_ACKNOWLEDGE);
              > topicPublisher = topicSession.createPublisher(topic);
              > textMessage = (TextMessage)inMessage;
              > topicPublisher.publish(inMessage);
              > // this is illegal in a container transaction
              > topicSession.commit();
              > topicConnection.close();
              > }
              > catch (JMSException je)
              > {
              > throw new EJBException(je);
              > }
              > catch (NamingException ne)
              > {
              > throw new EJBException(ne);
              > }
              > }
              >
              > public void ejbRemove()
              > {
              > }
              > }
              >
              >
              >
              >
              > <?xml version="1.0" encoding="UTF-8"?>
              >
              > <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
              > JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
              >
              > <ejb-jar>
              > <enterprise-beans>
              > <message-driven>
              > <display-name>MessageBean</display-name>
              > <ejb-name>MessageBean</ejb-name>
              > <ejb-class>MessageBean</ejb-class>
              > <transaction-type>Container</transaction-type>
              > <message-driven-destination>
              > <destination-type>javax.jms.Queue</destination-type>
              > </message-driven-destination>
              > <security-identity>
              > <description></description>
              > <run-as>
              > <description></description>
              > <role-name></role-name>
              > </run-as>
              > </security-identity>
              > </message-driven>
              > </enterprise-beans>
              > <assembly-descriptor>
              > <container-transaction>
              > <method>
              > <ejb-name>MessageBean</ejb-name>
              > <method-name>*</method-name>
              > </method>
              > <trans-attribute>Required</trans-attribute>
              > </container-transaction>
              > </assembly-descriptor>
              > </ejb-jar>
              >
              >
              >
              >
              >
              >
              >
              >
              

  • Transactional Behavior of an Integration Process

    Hi All,
    As I have to optimise an existing BPM, to have some idea, I was going through the link describing 'Transactional Behavior of an Integration Process'.
    http://help.sap.com/saphelp_nw04/Helpdata/EN/25/a45c3cff8ca92be10000000a114084/frameset.htm
    which tells tas follows.
    'At runtime, the system normally creates a separate transaction for each step. The transaction then covers this step only. However, you can influence the transactional behavior of particular step types. In the step properties, you can define that the system is not to start a new transaction when the step is executed. The system then executes the step in the transaction that was started at the time of execution. Consequently, no background work item is created for the step and the database does not need to be accessed. In this way you can improve system performance'
    But I am not able to understand, how to implement that for any steps. Could you please explain?
    Regards,
    Subhendu

    Hi Subhendu,
    i ve got some doubts it was in SP 17 available. Please search at [Release Notes for SAP Exchange Infrastructure|http://help.sap.com/saphelp_nw04/helpdata/en/c9/9844428e9cbe30e10000000a155106/frameset.htm]
    Regards,
    Udo
    Edited by: Udo Martens on Feb 5, 2009 3:38 PM

  • ORA-02049: timeout: distributed transaction waiting for lock

    Hi,
    My name is Guneet and I'm working on an application running on BEA Weblogic Server 9.2 running on a Red Hat Linux box using Oracle 10g as the database. My problem is that recently our code started getting the following exception while updating a database table.
    java.sql.SQLException: [BEA][Oracle JDBC Driver][Oracle]ORA-02049: timeout: distributed transaction waiting for lock
    Application Details
    * Using Stateless Session EJB
    * Only one Business method in this EJB with transaction attribute set to "required"
    * This method executes two select queries & one update query
    * We are using JDBC to access the database.
    * We have configured a Data Source & are using it to get a database connection.
    * Weblogic's Oracle Driver is being used.
    More details
    * The application has been running well since a month.
    * Two days ago,the update query failed with the above error.
    * At that time, a single client was accessing the system.
    * Once this problem occurs, it starts appearing frequently.
    * Eventually a request to get a connection from the Data Source times out & the exception copied at the end is thrown
    * At this stage the application gets stuck and all requests trying to get a connection end up with this exception.
    * Fortunately, Restarting the Weblogic Server gets us out of this problem and transactions resume normally.
    Now my questions are
    # Why is this error happening & what does it mean?
    # It looks like the second exception (unable to get a connection from ds) is an after effect of the first problem (ORA-02049) once it appears for a couple of times. Can somebody validate this?
    # Though I don't understand JTA well but I don't think this application needs distributed transactions so, I'm thinking of modifying the driver type to non-XA oracle driver. Any advise/pointers/comments on this front is welcome !!!!!!!!
    Thanks
    Guneet Sahai
    Exception Trace
    Dec 27, 2006 4:47:50 PM | com.gisil.themis.db | SEVERE | Unable to load merchant DEL = 911168900164. Reason - java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: XA error: XAResource.XAER_RMERR start() failed on resource 'themis-ds': XAER_RMERR : A resource manager error has occured in the transaction branch
    javax.transaction.xa.XAException: Unexpected error during start for XAResource 'themis-ds': Transaction timed out after 29 seconds
    BEA1-252DE51AC930078CA638
    at weblogic.jdbc.wrapper.XA.createException(XA.java:103)
    at weblogic.jdbc.jta.DataSource.start(DataSource.java:753)
    at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1182)
    at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1115)
    at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:274)
    at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:497)
    at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:429)
    at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1408)
    at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1332)
    at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:440)
    at weblogic.jdbc.jta.DataSource.connect(DataSource.java:396)
    at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:359)
    at com.gisil.themis.db.impl1.DbManagerImpl.isPinValid(DbManagerImpl.java:872)
    at com.gisil.themis.ejb.ThemisBean.isPinValid(ThemisBean.java:185)
    at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl.isPinValid(Themis_aqqc4k_EOImpl.java:207)
    at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl_WLSkel.invoke(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:517)
    at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
    at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:407)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
    at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:403)
    at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:56)
    at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:934)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
    at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1413)
    at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1332)
    at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:440)
    at weblogic.jdbc.jta.DataSource.connect(DataSource.java:396)
    at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:359)
    at com.gisil.themis.db.impl1.DbManagerImpl.isPinValid(DbManagerImpl.java:872)
    at com.gisil.themis.ejb.ThemisBean.isPinValid(ThemisBean.java:185)
    at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl.isPinValid(Themis_aqqc4k_EOImpl.java:207)
    at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl_WLSkel.invoke(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:517)
    at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
    at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:407)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
    at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:403)
    at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:56)
    at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:934)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)

    guneet sahai wrote:
    Hi,
    My name is Guneet and I'm working on an application running on BEA Weblogic Server 9.2 running on a Red Hat Linux box using Oracle 10g as the database. My problem is that recently our code started getting the following exception while updating a database table.
    java.sql.SQLException: [BEA][Oracle JDBC Driver][Oracle]ORA-02049: timeout: distributed transaction waiting for lock
    Application Details
    * Using Stateless Session EJB
    * Only one Business method in this EJB with transaction attribute set to "required"
    * This method executes two select queries & one update query
    * We are using JDBC to access the database.
    * We have configured a Data Source & are using it to get a database connection.
    * Weblogic's Oracle Driver is being used.
    More details
    * The application has been running well since a month.
    * Two days ago,the update query failed with the above error.
    * At that time, a single client was accessing the system.
    * Once this problem occurs, it starts appearing frequently.
    * Eventually a request to get a connection from the Data Source times out & the exception copied at the end is thrown
    * At this stage the application gets stuck and all requests trying to get a connection end up with this exception.
    * Fortunately, Restarting the Weblogic Server gets us out of this problem and transactions resume normally.
    Now my questions are
    # Why is this error happening & what does it mean?
    # It looks like the second exception (unable to get a connection from ds) is an after effect of the first problem (ORA-02049) once it appears for a couple of times. Can somebody validate this?
    # Though I don't understand JTA well but I don't think this application needs distributed transactions so, I'm thinking of modifying the driver type to non-XA oracle driver. Any advise/pointers/comments on this front is welcome !!!!!!!!
    Thanks
    Guneet SahaiHi Guneet. If you want to debug the JTA issue, I suggest opening an official
    support case. They will lead you through producing the JTA debug information.
    However, I believe you are correct that the transaction you describe is
    completely doable with a simple local transaction, so if you were to alter
    your pool to use the non-XA driver, it would probably be faster, simpler,
    and just work.
    Let me know...
    Joe
    >
    Exception Trace
    Dec 27, 2006 4:47:50 PM | com.gisil.themis.db | SEVERE | Unable to load merchant DEL = 911168900164. Reason - java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: XA error: XAResource.XAER_RMERR start() failed on resource 'themis-ds': XAER_RMERR : A resource manager error has occured in the transaction branch
    javax.transaction.xa.XAException: Unexpected error during start for XAResource 'themis-ds': Transaction timed out after 29 seconds
    BEA1-252DE51AC930078CA638
    at weblogic.jdbc.wrapper.XA.createException(XA.java:103)
    at weblogic.jdbc.jta.DataSource.start(DataSource.java:753)
    at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1182)
    at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1115)
    at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:274)
    at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:497)
    at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:429)
    at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1408)
    at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1332)
    at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:440)
    at weblogic.jdbc.jta.DataSource.connect(DataSource.java:396)
    at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:359)
    at com.gisil.themis.db.impl1.DbManagerImpl.isPinValid(DbManagerImpl.java:872)
    at com.gisil.themis.ejb.ThemisBean.isPinValid(ThemisBean.java:185)
    at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl.isPinValid(Themis_aqqc4k_EOImpl.java:207)
    at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl_WLSkel.invoke(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:517)
    at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
    at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:407)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
    at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:403)
    at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:56)
    at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:934)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
    at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1413)
    at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1332)
    at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:440)
    at weblogic.jdbc.jta.DataSource.connect(DataSource.java:396)
    at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:359)
    at com.gisil.themis.db.impl1.DbManagerImpl.isPinValid(DbManagerImpl.java:872)
    at com.gisil.themis.ejb.ThemisBean.isPinValid(ThemisBean.java:185)
    at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl.isPinValid(Themis_aqqc4k_EOImpl.java:207)
    at com.gisil.themis.ejb.Themis_aqqc4k_EOImpl_WLSkel.invoke(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:517)
    at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
    at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:407)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
    at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:403)
    at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:56)
    at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:934)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)

Maybe you are looking for

  • IPOD Mini is not recognized by my PC

    Help! I can't restore/update my Ipod Mini because my PC won't recognize it. When I reset the Ipod I get a folder/! or an Apple symbol - nothing more. The computer seems to be able to charge the Ipod, but doesn't recognize it - doesn't start Itunes, s

  • TS3221 i have an error (0xE800005E) my itunes won't recognise my ipod and i need to reactivate it and carn't do so help please

    i have an error(0xe800005E) that my 5 year old son created i tryed 2 connect 2 itunes 2 reactivate his ipod and it wont recognise his ipod how can i fix his ipod

  • Iviews in Performance Management

    Hi , I am trying to understand the difference between the below options available in the Manager Documents tab in MSS view. 1. Direct Report to Appraise 2. Employee to Appraise 3. Direct Reports 4. Direct Reports to Leader. Help appreciated as the re

  • Vista Bootcamp, problem running drivers no sound or airport

    Hello I have installed Vista on my Macbook pro via Bootcamp I have tried to install drives from here - http://support.apple.com/downloads/Boot_Camp_Update_2_1_for_Windows_Vista_32 And also Burned a cd version of the drives from the bootcamp assistent

  • Select unique rows from two tables...

    Hi, I have two tables, replies1 and replies2. SQL> desc replies Name Null? Type URN VARCHAR2(36) ADDRESS VARCHAR2(18) FILESIZE NUMBER AS_NUM VARCHAR2(6) SQL> desc replies2 Name Null? Type URN VARCHAR2(36) ADDRESS VARCHAR2(18) AS_NUM VARCHAR2(6) Both