Issue in Visual Notification During Long Running Transactions

Hi,
I am using Jdev 11.1.1.5.0 for developement.
In my application i am having af:table. in that table i am having a column as af:selectBooleanCheckbox. My Need is avoid clicking a selectBooleanCheckbox twice or changing data input while waiting for a long running process to complete. I follows Frank Nimphius have written articles in the past http://www.oracle.com/technetwork/developer-tools/adf/learnmore/27-long-running-queries-169166.pdf but my appliaction i use af:clientListener component for af:selectBooleanCheckbox. when i click the checbox in table, popup(progress popup) is not opening and it also allow user to enter some other data in my page.
Pls help...
- Vinoth

In Jsff
  <af:resource type="javascript">
   function enforcePreventUserInput(evt) {
       var popup = AdfPage.PAGE.findComponentByAbsoluteId('progressId');
       if (popup != null) {
           AdfPage.PAGE.addBusyStateListener(popup, handleBusyState);
           evt.preventUserInput();
   function handleBusyState(evt) {
       var popup = AdfPage.PAGE.findComponentByAbsoluteId('progressId');
       if (popup != null) {
           if (evt.isBusy()) {
               popup.show();
           else if (popup.isPopupVisible()) {
               popup.hide();
               AdfPage.PAGE.removeBusyStateListener(popup, handleBusyState);
</af:resource>
  <af:popup id="progressId" contentDelivery="immediate">
   <af:dialog id="dcx2" type="none" title="Long Running Process ..."
              closeIconVisible="false">
    <af:panelGroupLayout id="pgl1dd" layout="vertical">
     <af:image source="/images/left" id="isdfs1"/>
     <af:image source="/images/animbar.gif" id="idf2"
               inlineStyle="width:197px;"/>
     <af:outputText value="... please wait" id="odfg11"/>
    </af:panelGroupLayout>
   </af:dialog>
  </af:popup>
{noformat}within af:table{noformat}
  <af:column sortProperty="SeriesID" align="center" width="54px"
                 headerText=" " id="c22">
       <af:selectBooleanCheckbox autoSubmit="true" label="select" id="sbc2"
                                 binding="#{pageFlowScope.MyBean.applicableValue}"
                                 valueChangeListener="#{pageFlowScope.MyBean.onValChngofChkBox}">
                                 <af:clientListener method="enforcePreventUserInput" type="click"/>
                                 </af:selectBooleanCheckbox>
      </af:column>

Similar Messages

  • Explicit commit during a long-running transaction in EclipseLink

    Hi,
    I am currently upgrading a J2EE application from OAS with Toplink Essentials to WL 10.3.3 with Eclipselink and have the following issue with transactions.
    The application was developed to have long-running transactions for business reasons in specific scenarios. However, some other queries must be created and committed along the way to make sure that we have this specific data in the database before the final commit. This call (and subsequent code) is in an EJB method that has the "@TransactionAttribute(TransactionAttributeType.REQUIRED)" defined on it. Taking this out gives me the same behaviour.
    The application has the following implementation of the process, which fails:
    Code
    EntityManager em = PersistenceUtil.createEntityManager();
    em.getTransaction().begin();
    PersistenceUtil.saveOrUpdate(em,folder);
    em.getTransaction().commit(); --->>>>FAILS HERE
    Error
    javax.ejb.EJBTransactionRolledbackException: EJB Exception: : javax.persistence.RollbackException: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.0.2.v20100323-r6872): org.eclipse.persistence.exceptions.DatabaseException Internal Exception: java.sql.SQLException: Cannot call Connection.rollback in distributed transaction. Transaction Manager will commit the resource manager when the distributed transaction is committed.
    So I tried the following to see if it would work, but I believe that the transaction end and anything after that will fail since it requires a transaction to continue
    PersistenceUtil.getUnitOfWork().writeChanges();
    PersistenceUtil.getUnitOfWork().commit();
    Error
    javax.persistence.TransactionRequiredException: joinTransaction has been called on a resource-local EntityManager which is unable to register for a JTA transaction.
    Can anyone help me as to how to commit a transaction within the long running transaction in this environment? I also want to be sure that the long-running transaction does not fail or is not stopped along the way.
    Thanking you in advance

    You seem to be using JTA, so you cannot use JPA transactions, you must defined your transaction in JTA, such as in your SessionBean.
    When using JTA you should never use,
    em.getTransaction().begin();
    If you do not want to use JTA, then you need to set your persistence unit to be RESOURCE_LOCAL in your persistence.xml.
    Also you need to ensure you use a non-jta enabled DataSource.
    James : http://www.eclipselink.org

  • Long-running transactions and the performance penalty

    If I change the orch or scope Transaction Type to "Long Running" and do not create any other transaction scopes inside, I'm getting this warning:
    warning X4018: Performance Warning: marking service '***' as a longrunning transaction is not necessary and incurs the performance penalty of an extra commit
    I didn't find any description of such penalties.
    So my questions to gurus:
    Does it create some additional persistence point(s) / commit(s) in LR orchestration/scope?
    Where are these persistence points happen, especially in LR orchestration?
    Leonid Ganeline [BizTalk MVP] BizTalk Development Architecture

    The wording may make it sound so but IMHO, if during the build of an orchestration we get carried away with scope shapes we end up with more persistence points which do affect the performance so one additional should not make soo much of a difference. It
    may have been put because of end-user feed back where people may have opted for long running transactions without realizing about performance overheads and in subsequent performance optimization sessions with Microsoft put it on the product enhancement list
    as "provide us with an indication if we're to incurr performance penalties". A lot of people design orchestration like they write code (not saying that is a bad thing) where they use the scope shape along the lines of a try catch block and what with
    Microsoft marketing Long Running Transactions/Compensation blocks as USP's for BizTalk, people did get carried away into using them without understanding the implications.
    Not saying that there is no additional persistence points added but just wondering if adding one is sufficient to warrant the warning. But if I nest enough scope shapes and mark them all as long-running, they may add up.
    So when I looked at things other than persistence points, I tried to think on how one might implement the long running transaction (nested, incorporating atomic, etc), would you be able to leverage the .Net transaction object (something the pipeline
    use and execute under) or would that model not handle the complexities of the Long Running Transaction which by very definiton span across days/months and keeping .Net Transaction objects active or serialization/de-serialization into operating context will
    cause more issues.
    Regards.

  • Will rollback failure cause long-running transaction?

    We are getting the following error for one transaction
    [TimesTen][TimesTen 5.1.35 CLIENT]Communication link failure. System call select() failed with OS error 110. This operation has Timed Out. Try increasing your ODBC timeout attribute or check to make sure the target TimesTen Server is running
    After that application tries to do a rollback, but rollback failed.
    Will this transaction become a long-running transaction in server?

    Have you filed a metalink SR to get help on this issue?
    -scheung

  • Long running transactions.

    Hi all,
    In real world systems, how efficient are long running flat transactions in ejb 2.0 since the transactions tends to lock several tables that are part of the transaction.
    Could any one explain in detail or direct to any websites that share the real time experiences with transactions in ejb enviornment.
    Thanks in advance.

    Long run transaction are real performance killers, avoid them if you can.
    It's actually quite easy (and sensible) to break down long transactions into smaller transactions with a little common-sense.
    For example, funds transfer. Say you want to transfer money from one account to another account from country A (which is only open on Tuesdays) to country B (only open on Fridays).
    Option A: Start a long running transaction on Tuesday, commit it on Friday.
    The resources used to do this are very much wasted - and will cause performance degradation.
    Option B: Transfer the funds from Country A to Country C (which is open Tuesday and Friday) - in one transaction on Tuesday. Transfer funds from Country C to country B in a second transaction on Friday. If C to B fails, transfer the funds back - if it succeeds inform A of the success. It's more complex, but there's no free lunch. (This is how real banks do it - ever got a refund from the bank? Well, no, but you know what I mean; it's also why it takes five days for a cheque to clear etc etc).
    This is only a narrative - but there are very few cases where this cannot work in a real transaction.

  • RZ20 - Is there an alert for long running transactions?

    In RZ20 is there an alert for long running transactions?

    http://help.sap.com/saphelp_nw04s/helpdata/en/9c/f78b3ba19dfe47e10000000a11402f/content.htm
    This document clearly explains your problem.
    "Reward points if useful"

  • Problem handing long running transaction

    Hi,
    I have a long running transaction, and there is a high possibility that
    someone else will make changes to one of the same objects in that
    transaction. How is everyone handling this situation? Is it best to
    catch the JDOException thrown and attempt the transaction one more time
    or to return to the user on "failure"?
    Also, would it possible with Kodo to set Pessimistic transactions for
    just this case and use optimistic for "read" operations?
    Kam

    Also, would it possible with Kodo to set Pessimistic transactions for
    just this case and use optimistic for "read" operations?You can easily switch between optimistic and pessimistic transactions:
    pm.currentTransaction ().setOptimistic (val);
    You can also use pessimistic transactions for everything, and set the
    nontransactional read property to true to do reads outside of transactions.
    Note, however, that you shouldn't use pessimistic locking for long-running
    transactions in most cases. They use too many DB resources. It's better to
    use optimistic transacactions and deal with the errors (or give them to the
    user).

  • IMDB Cache group load and long running transaction

    Hello,
    We are investigating the use of IMDB Cache to cache a number of large Oracle tables. When loading the cache I have noticed logs accumulating and I am not quite sure why this should be. I have a read only cache group consisting of 3 tables with approximatley, 88 million rows, 74 million rows and 570 million rows in each table. To load the cache group I run the following -
    LOAD CACHE GROUP er_ro_cg COMMIT EVERY 1000 ROWS PARALLEL 10 ;ttLogHolds shows -
    Command> call ttLogHolds ;
    < 0, 12161024, Long-Running Transaction      , 1.1310 >
    < 170, 30025728, Checkpoint                    , Entity.ds0 >
    < 315, 29945856, Checkpoint                    , Entity.ds1 >
    3 rows found.I read this as saying from log 0 to current must be kept for the long running transaction. From what I can see the long running transaction is the cache group load. Is this expected? I was expecting the commit in the load cache group to allow the logs to be deleted. I am able to query the contents of the tables at various times in the load so I can see that the commit is taking place.
    Thanks
    Mark

    Hello,
    I couldn't recall whether I had changed the Autocommit settings when I ran the load so I tried a couple more runs. From what I could see the value of autocommit did not influence how the logs were treated. For example -
    1. Autocommit left as the default -
    Connection successful: DSN=Entity;UID=cacheadm;DataStore=/prod100/oradata/ENTITY/Entity;DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;DRIVER=/app1/oracle/product/11.2.0/TimesTen/ER/lib/libtten.so;LogDir=/prod100/oradata/ENTITY;PermSize=66000;TempSize=2000;TypeMode=0;OracleNetServiceName=TRAQPP.world;
    (Default setting AutoCommit=1)
    Command> LOAD CACHE GROUP er_ro_cg COMMIT EVERY 1000 ROWS PARALLEL 10 ;Logholds shows a long running transaction -
    Command> call ttlogholds ;
    < 0, 11915264, Long-Running Transaction      , 1.79 >
    < 474, 29114368, Checkpoint                    , Entity.ds0 >
    < 540, 1968128, Checkpoint                    , Entity.ds1 >
    3 rows found.And ttXactAdmin shows only the load running -
    2011-01-19 14:10:03.135
    /prod100/oradata/ENTITY/Entity
    TimesTen Release 11.2.1.6.1
    Outstanding locks
    PID     Context            TransID     TransStatus Resource  ResourceID           Mode  SqlCmdID             Name
    Program File Name: timestenorad
    28427   0x16fd6910            7.26     Active      Database  0x01312d0001312d00   IX    0                   
                                                       Table     718080               W     69211971680          TRAQDBA.ENT_TO_EVIDENCE_MAP
                                                       Table     718064               W     69211971680          TRAQDBA.AADNA
                                                       Command   69211971680          S     69211971680         
                                  8.10029  Active      Database  0x01312d0001312d00   IX    0                   
                                  9.10582  Active      Database  0x01312d0001312d00   IX    0                   
                                 10.10477  Active      Database  0x01312d0001312d00   IX    0                   
                                 11.10332  Active      Database  0x01312d0001312d00   IX    0                   
                                 12.10546  Active      Database  0x01312d0001312d00   IX    0                   
                                 13.10261  Active      Database  0x01312d0001312d00   IX    0                   
                                 14.10637  Active      Database  0x01312d0001312d00   IX    0                   
                                 15.10669  Active      Database  0x01312d0001312d00   IX    0                   
                                 16.10111  Active      Database  0x01312d0001312d00   IX    0                   
    Program File Name: ttIsqlCmd
    29317   0xde257d0             1.79     Active      Database  0x01312d0001312d00   IX    0                   
                                                       Row       BMUFVUAAAAKAAAAPD0   S     69211584104          SYS.TABLES
                                                       Command   69211584104          S     69211584104         
    11 outstanding transactions foundAnd the commands were
    < 69211971680, 2048, 1, 1, 0, 0, 1392, CACHEADM                       , load cache group CACHEADM.ER_RO_CG commit every 1000 rows parallel 10 _tt_bulkFetch 4096 _tt_bulkInsert 1000 >
    < 69211584104, 2048, 1, 1, 0, 0, 1400, CACHEADM                       , LOAD CACHE GROUP er_ro_cg COMMIT EVERY 1000 ROWS PARALLEL 10 >Running the load again with autocommit off -
    Command> AutoCommit
    autocommit = 1 (ON)
    Command> AutoCommit 0
    Command> AutoCommit
    autocommit = 0 (OFF)
    Command> LOAD CACHE GROUP er_ro_cg COMMIT EVERY 1000 ROWS PARALLEL 10 ;Logholds shows a long running transaction
    Command>  call ttlogholds ;
    < 1081, 6617088, Long-Running Transaction      , 2.50157 >
    < 1622, 10377216, Checkpoint                    , Entity.ds0 >
    < 1668, 55009280, Checkpoint                    , Entity.ds1 >
    3 rows found.And ttXactAdmin shows only the load running -
    er.oracle$ ttXactAdmin entity                                             
    2011-01-20 07:23:54.125
    /prod100/oradata/ENTITY/Entity
    TimesTen Release 11.2.1.6.1
    Outstanding locks
    PID     Context            TransID     TransStatus Resource  ResourceID           Mode  SqlCmdID             Name
    Program File Name: ttIsqlCmd
    2368    0x12bb37d0            2.50157  Active      Database  0x01312d0001312d00   IX    0                   
                                                       Row       BMUFVUAAAAKAAAAPD0   S     69211634216          SYS.TABLES
                                                       Command   69211634216          S     69211634216         
    Program File Name: timestenorad
    28427   0x2abb580af2a0        7.2358   Active      Database  0x01312d0001312d00   IX    0                   
                                                       Table     718080               W     69212120320          TRAQDBA.ENT_TO_EVIDENCE_MAP
                                                       Table     718064               W     69212120320          TRAQDBA.AADNA
                                                       Command   69212120320          S     69212120320         
                                  8.24870  Active      Database  0x01312d0001312d00   IX    0                   
                                  9.26055  Active      Database  0x01312d0001312d00   IX    0                   
                                 10.25659  Active      Database  0x01312d0001312d00   IX    0                   
                                 11.25469  Active      Database  0x01312d0001312d00   IX    0                   
                                 12.25694  Active      Database  0x01312d0001312d00   IX    0                   
                                 13.25465  Active      Database  0x01312d0001312d00   IX    0                   
                                 14.25841  Active      Database  0x01312d0001312d00   IX    0                   
                                 15.26288  Active      Database  0x01312d0001312d00   IX    0                   
                                 16.24924  Active      Database  0x01312d0001312d00   IX    0                   
    11 outstanding transactions foundWhat I did notice was that TimesTen runs three queries against the Oracle server, the first to select from the parent table, the second to join the parent to the first child and the third to join the parent to the second child. Logholds seems to show a long running transaction once the second query starts. For example, I was monitoring the load of the parent table, checking ttlogholds to watch for a long running transaction. As shown below, a long running transaction entry appeared around 09:01:41 -
    Command> select sysdate from dual ;
    < 2011-01-20 09:01:37 >
    1 row found.
    Command> call ttlogholds ;
    < 2427, 39278592, Checkpoint                    , Entity.ds1 >
    < 2580, 22136832, Checkpoint                    , Entity.ds0 >
    2 rows found.
    Command> select sysdate from dual ;
    < 2011-01-20 09:01:41 >
    1 row found.
    Command> call ttlogholds ;
    < 2427, 39290880, Long-Running Transaction      , 2.50167 >
    < 2580, 22136832, Checkpoint                    , Entity.ds0 >
    < 2929, 65347584, Checkpoint                    , Entity.ds1 >
    3 rows found.This roughly matches the time the query that selects the rows for the first child table started in Oracle
    traqdba@TRAQPP> select sm.sql_id,sql_exec_start,sql_fulltext
      2  from v$sql_monitor sm, v$sql s
      3  where sm.sql_id = 'd6fmfrymgs5dn'
      4  and sm.sql_id = s.sql_id ;
    SQL_ID        SQL_EXEC_START       SQL_FULLTEXT
    d6fmfrymgs5dn 20/JAN/2011 08:59:27 SELECT "TRAQDBA"."ENT_TO_EVIDENCE_MAP"."ENTITY_KEY", "TRAQDBA"."ENT_TO_EVIDENCE_
                                       MAP"."EVIDENCE_KEY", "TRAQDBA"."ENT_TO_EVIDENCE_MAP"."EVIDENCE_VALUE", "TRAQDBA"
                                       ."ENT_TO_EVIDENCE_MAP"."CREATED_DATE_TIME" FROM "TRAQDBA"."ENT_TO_EVIDENCE_MAP",
                                        "TRAQDBA"."AADNA" WHERE "TRAQDBA"."ENT_TO_EVIDENCE_MAP"."ENTITY_KEY" = "TRAQDBA
                                       "."AADNA"."ADR_ADDRESS_NAME_KEY"
    Elapsed: 00:00:00.00Thanks
    Mark

  • Sequential Convoy and Long running transaction: Messages still referenced

    Hi everyone<o:p></o:p>
    Being a BizTalk developer since 2006, this thing still stumps me.<o:p></o:p>
    I have a sequential convoy singleton orchestration that debatches messages using a rcvPipeline. The orchestration is needed in a FIFO scenario. In order to execute a rcvPipeline
    within an orchestration I need to encapsulate it within an atomic transaction scope. <o:p></o:p>
    In order to have an atomic scope the orchestration needs to be long running. I have also encapsulated the atomic transaction within a scope (using long running transactions) to have
    exception handling.
    <o:p></o:p>
    Everything works fine except for one major detail:
    When the orchestration executes the messages are still in the messagebox. I can even click on the orchestration instance in the MGMT console and look at the message! Tracking is disabled for the receive port as well as for the orchestration. Still, the messages
    does not get cleaned up.
    <o:p></o:p>
    I have set my DTA-purge to 1 hour and it works fine, but the messages are still in the orchestration.<o:p></o:p>
    My guess is that the long running transactions does not complete (although it looks like they should) and since the transaction is not completed the messages are not removed from
    the message box.
    So, to summarize: Is it possible to combine long running transactions and a singleton orchestration?
    //Mikael Sand (MCTS, ICC 2011) -
    Blog Logica Sweden

    So after a day of looking for the solution it is quite clear that you are right in that the atomic transaction does not commit. I added a compensation block with trace info and it is never hit.
    I also experimented with Isolation level on the atomic transaction and that did nothing.
    Lastly I also made the sendport direct bound and also tried "specify later binding" to a physical port.
    The messages are still being referenced by the orchestration! What can I do to make the atomic transation commit?
    //Mikael Sand (MCTS, ICC 2011) -
    Blog Logica Sweden

  • Is there any time out defined for long running transaction?

    hi, 
    i have to make one big data transferring script , though transaction is not required here, but i was planning to,
    please tel me is there any time out for long running transactions.i have to run the script from database it self
    yours sincerley

    Can you show us an example of your script? You can divide the transaction into small chunks to reduce time and locking/blocking as well.
    Best Regards,Uri Dimant SQL Server MVP,
    http://sqlblog.com/blogs/uri_dimant/
    MS SQL optimization: MS SQL Development and Optimization
    MS SQL Consulting:
    Large scale of database and data cleansing
    Remote DBA Services:
    Improves MS SQL Database Performance
    SQL Server Integration Services:
    Business Intelligence

  • Using MDBs for long running transactions

    Although MDBs are not the best vehicles for running long transactions, I am
              forced to use them for one such scenario (let's say for lack of a better
              pattern). In order to let my long running MDB (with Container Managed Tx)
              do it's chores I increased the time-out value to a higher number rather than
              using the default of 30 secs. Strangely, I was seeing
              IllegalStateExceptions in stdout. So I created a brand new test MDB with a
              Thread.sleep for 60 seconds, increased my MDBs timeout value to 120 secs,
              made sure there was only one MDB in the pool and ran the test again. I
              still see the below error after 30 seconds.
              I guess I should probably open a support case, but I thought I'll post here
              as well in case there's something I am missing.
              <May 27, 2003 5:26:31 PM PDT> <Notice> <EJB> <Error marking transaction for
              rollback: java.lang.IllegalStateException: Cannot m
              ark the transaction for rollback. xid=64:bea55f200db2c786, status=Rolled
              back. [Reason=weblogic.transaction.internal.TimedOutEx
              ception: Transaction timed out after 34 seconds
              Xid=64:bea55f200db2c786(-33600248),Status=Active,numRepliesOwedMe=0,numRepli
              esOwedOthers=0,seconds since begin=34,seconds left=
              30,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread
              Group for Queue: 'default'],ServerResourceInfo[JMS_hmJD
              BCStore]=(state=started,assigned=none),SCInfo[wlcsDomain+wlcsServer]=(state=
              active),OwnerTransactionManager=ServerTM[ServerCoor
              dinatorDescriptor=(CoordinatorURL=wlcsServer+155.14.3.140:7501+wlcsDomain+,
              Resources={})],CoordinatorURL=wlcsServer+155.14.3.1
              40:7501+wlcsDomain+)]
              java.lang.IllegalStateException: Cannot mark the transaction for rollback.
              xid=64:bea55f200db2c786, status=Rolled back. [Reason
              =weblogic.transaction.internal.TimedOutException: Transaction timed out
              after 34 seconds
              Xid=64:bea55f200db2c786(-33600248),Status=Active,numRepliesOwedMe=0,numRepli
              esOwedOthers=0,seconds since begin=34,seconds left=
              30,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread
              Group for Queue: 'default'],ServerResourceInfo[JMS_hmJD
              BCStore]=(state=started,assigned=none),SCInfo[wlcsDomain+wlcsServer]=(state=
              active),OwnerTransactionManager=ServerTM[ServerCoor
              dinatorDescriptor=(CoordinatorURL=wlcsServer+155.14.3.140:7501+wlcsDomain+,
              Resources={})],CoordinatorURL=wlcsServer+155.14.3.1
              40:7501+wlcsDomain+)]
              at
              weblogic.transaction.internal.TransactionImpl.throwIllegalStateException(Tra
              nsactionImpl.java:1486)
              at
              weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImp
              l.java:466)
              at
              weblogic.ejb20.manager.BaseEJBManager.handleSystemException(BaseEJBManager.j
              ava:255)
              at
              weblogic.ejb20.manager.BaseEJBManager.setupTxListener(BaseEJBManager.java:21
              5)
              at
              weblogic.ejb20.manager.StatelessManager.preInvoke(StatelessManager.java:153)
              at
              weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:117)
              at
              weblogic.ejb20.internal.StatelessEJBObject.preInvoke(StatelessEJBObject.java
              :63)
              at
              com.xoriant.hm.ejb.session.HierarchyManagerBean_fzysig_EOImpl.getHierarchyId
              (HierarchyManagerBean_fzysig_EOImpl.java
              :1477)
              at
              com.ebiz.application.customerprofile.hm.CPXHMController.SynchronizeMHTH(Unkn
              own Source)
              at
              com.ebiz.application.customerprofile.hm.CPHMOrgGroupMsgBean.onMessage(Unknow
              n Source)
              at weblogic.ejb20.internal.MDListener.execute(MDListener.java:254)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              

    Hi Adarsh,
              It may be that the transaction time-out setting in the descriptor
              is not taking effect. The tx is still timing out after
              the default 30 seconds, so the later attempt to call
              "setRollbackOnly" fails as the transaction has already
              rolled back The ignored descriptor setting is a known issue
              in some earlier SPs, but I'm not sure when and where it
              was fixed - so yes, contact customer support. The work-around
              is to set the default transaction time-out for the entire server to a
              higher value. (I'm not sure where to set this on the console,
              but the relevant JTA MBean field is "TimeoutSeconds".)
              Tom
              Adarsh Dattani wrote:
              > Although MDBs are not the best vehicles for running long transactions, I am
              > forced to use them for one such scenario (let's say for lack of a better
              > pattern). In order to let my long running MDB (with Container Managed Tx)
              > do it's chores I increased the time-out value to a higher number rather than
              > using the default of 30 secs. Strangely, I was seeing
              > IllegalStateExceptions in stdout. So I created a brand new test MDB with a
              > Thread.sleep for 60 seconds, increased my MDBs timeout value to 120 secs,
              > made sure there was only one MDB in the pool and ran the test again. I
              > still see the below error after 30 seconds.
              > I guess I should probably open a support case, but I thought I'll post here
              > as well in case there's something I am missing.
              >
              > <May 27, 2003 5:26:31 PM PDT> <Notice> <EJB> <Error marking transaction for
              > rollback: java.lang.IllegalStateException: Cannot m
              >
              > ark the transaction for rollback. xid=64:bea55f200db2c786, status=Rolled
              > back. [Reason=weblogic.transaction.internal.TimedOutEx
              >
              > ception: Transaction timed out after 34 seconds
              >
              > Xid=64:bea55f200db2c786(-33600248),Status=Active,numRepliesOwedMe=0,numRepli
              > esOwedOthers=0,seconds since begin=34,seconds left=
              >
              > 30,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread
              > Group for Queue: 'default'],ServerResourceInfo[JMS_hmJD
              >
              > BCStore]=(state=started,assigned=none),SCInfo[wlcsDomain+wlcsServer]=(state=
              > active),OwnerTransactionManager=ServerTM[ServerCoor
              >
              > dinatorDescriptor=(CoordinatorURL=wlcsServer+155.14.3.140:7501+wlcsDomain+,
              > Resources={})],CoordinatorURL=wlcsServer+155.14.3.1
              >
              > 40:7501+wlcsDomain+)]
              >
              > java.lang.IllegalStateException: Cannot mark the transaction for rollback.
              > xid=64:bea55f200db2c786, status=Rolled back. [Reason
              >
              > =weblogic.transaction.internal.TimedOutException: Transaction timed out
              > after 34 seconds
              >
              > Xid=64:bea55f200db2c786(-33600248),Status=Active,numRepliesOwedMe=0,numRepli
              > esOwedOthers=0,seconds since begin=34,seconds left=
              >
              > 30,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread
              > Group for Queue: 'default'],ServerResourceInfo[JMS_hmJD
              >
              > BCStore]=(state=started,assigned=none),SCInfo[wlcsDomain+wlcsServer]=(state=
              > active),OwnerTransactionManager=ServerTM[ServerCoor
              >
              > dinatorDescriptor=(CoordinatorURL=wlcsServer+155.14.3.140:7501+wlcsDomain+,
              > Resources={})],CoordinatorURL=wlcsServer+155.14.3.1
              >
              > 40:7501+wlcsDomain+)]
              >
              > at
              > weblogic.transaction.internal.TransactionImpl.throwIllegalStateException(Tra
              > nsactionImpl.java:1486)
              >
              > at
              > weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImp
              > l.java:466)
              >
              > at
              > weblogic.ejb20.manager.BaseEJBManager.handleSystemException(BaseEJBManager.j
              > ava:255)
              >
              > at
              > weblogic.ejb20.manager.BaseEJBManager.setupTxListener(BaseEJBManager.java:21
              > 5)
              >
              > at
              > weblogic.ejb20.manager.StatelessManager.preInvoke(StatelessManager.java:153)
              >
              > at
              > weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:117)
              >
              > at
              > weblogic.ejb20.internal.StatelessEJBObject.preInvoke(StatelessEJBObject.java
              > :63)
              >
              > at
              > com.xoriant.hm.ejb.session.HierarchyManagerBean_fzysig_EOImpl.getHierarchyId
              > (HierarchyManagerBean_fzysig_EOImpl.java
              >
              > :1477)
              >
              > at
              > com.ebiz.application.customerprofile.hm.CPXHMController.SynchronizeMHTH(Unkn
              > own Source)
              >
              > at
              > com.ebiz.application.customerprofile.hm.CPHMOrgGroupMsgBean.onMessage(Unknow
              > n Source)
              >
              > at weblogic.ejb20.internal.MDListener.execute(MDListener.java:254)
              >
              > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              >
              > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              >
              >
              >
              >
              

  • ADF BC: Long running transactions

    Hello Everyone,
    Do you know how does a transaction works on ADF Business Components? I ask this because as part of my application I will build a long-running process where I'll update lots of complex data structures that won't fit in memory all at once. What steps can I follow to avoid an OutOfMemoryError?
    Thanks!
    Juan Manuel

    Hi Juan check this link [http://download-west.oracle.com/docs/cd/B32110_01/web.1013/b25947/bcvoeo.htm#sthref606] there is good information about how works the transactions in ADF BC.
    In the case of OutOfMemoryError, particulary in a query always test the code in a SQLDeveloper or PL/SQL Developer, check also the PermGen space of your JDeveloper and your APP server.
    Good Luck.

  • Disabling UNDO altogether so long running transactions have no rollback

    Hi, we have a large Oracle 11g database that we use only to demo our product to potential customers. It's not an important database as far as the quality of the data, it serves its purpose. Well every night we run a script to increment all the date fields in the database so our demos are predictable for our sales people. This date rolling results in a huge UNDO tablespace and we really can't justify the space to house it. How can I turn off transactions altogether so long running queries just commit row by row with no rollback and no writing to the undo tablespace?

    Yes:
    Oracle saves undo data at least until the transaction has been committed. Until this time, the undo data is in the active state. Therefore, the amount of space available in the undo tablespace should be at least large enough to hold the active undo data generated by current transactions. Otherwise, some of these transactions might fail. When active undo data is stored in the undo tablespace, Oracle automatically ensures that it is never overwritten until the corresponding transaction has been committed.
    From http://download.oracle.com/docs/cd/B19306_01/server.102/b14196/storage003.htm.

  • Email Notification for long running session

    Dear All,
    I want to configure email notification for any long running session on my server which can be seen in SM66. Is there any possible way? Please suggest.
    Regards,
    Prem

    Hi Prem,
    I hope you doing good.
    Now, for the above query, I am not sure that we have any such MTE in CCMS for user specific session, however, a small custom code can be used to achieve such functions
    Here, you have to use some f Function Modules using CALL FUNCTION/FM in your abap code.
    These function modules are from TH* family like TH_DISPLAY_USER_LIST and TH_USER_INFO. Now the coder can file out the results based on some 'Threshold', which are in spool generated - convert this into PDF(if you want). Now schedules this custom program in background for every 10 mins, and notification will come through it on email ID or any DL.
    How to send email from job - How to email output from Background Jobs
    Regards,
    Divyanshu

  • TPETIME and long running transactions

    Tuxedo version and patch: Tuxedo Version 8.1, 32-bit, Patch Level 328
    Issue:
    One of the services we have is exhibiting very high response times (as gathered from the stderr log using -r option). In some instances the reported response time has reached 827 seconds. Now, my understanding says that since the default timeout in Tuxedo is set to 300 seconds, the service should have timed out and it did not. I checked if there is a SVCTIMEOUT setting for this service in the ubbconfig file, but there is not.
    I am confused as in why this service did not timeout as expected? Is there a known issue with Tuxedo 8.1 and is there a patch for it (i searched the forum but didn't find any)?
    Any help/hints appreciated.

    Hi,
    there are many different kinds of timeouts available in Tuxedo and it might feel confusing sometimes.
    Timeouts can be viewed from two different perspectives - that of the client (calling the service) and that of the service/server itself.
    From the client's point of view, a service call using tpcall() is generally subject to a timeout, defined by BLOCKTIME*SCANUNIT in the ubbconfig, or a service-specific BLOCKTIME in newer versions of Tuxedo (called "blocking timeout", default 60 seconds). If the service call lasts (more than SCANUNIT seconds) longer than the blocking timeout, tpcall() will fail with tperrno TPETIME.
    The client can avoid this by setting the flag TPNOTIME, in which case the tpcall() call will "hang" until the service finally returns something. (I would personally recommend against this, but that's another story...)
    From the service/servers point of view, a blocking timeout is never really an issue (unless the service performs a nested call, but in that case it becomes a client!). The service will continue its work until it finally reaches the point of tpreturn() (or possibly tpforward()). It has no real understanding that the client might have given up a long time ago (with a TPETIME error), it will do whatever it takes to try to deliver a response, sometimes causing entries in the ULOG if the client has terminated and the delivery is impossible.
    If you want to avoid this, you need to define a SVCTIMEOUT in the ubbconfig for the service in question. If you do that, Tuxedo will monitor the server side of the service call and brutally abort the server process (kill it by means of a unix signal) if a service call hosted by that process lasts (more than SCANUNIT seconds) longer than the SVCTIMEOUT specified for that service. If you have defined the server with RESTART=Y (and MAXGEN=n!!!), Tuxedo will then restart the server automatically, which is probably a good thing. I'm not 100% sure what the client will receive, but probably a TPETIME. (If you have specified TPNOTIME you might actually get into trouble in this case.)
    In order not to make things too easy, there's also the possibility of a transactional timeout (as opposed to blocking timeout). A transactional timeout is a mechanism to protect databases and other users from transactions/locks with too long durations, and as such is is somewhat more potent than a blocking timeout (that is only protecting a single client from waiting too long).
    If a transactional timeout is in effect, it will always override the blocking timeout.
    To return to your question, it is my belief that the client in your case experienced a timeout (TPETIME) error after some 300 seconds, if that's your configured BLOCKTIME (60 used to be the default). As the server did not really know this, it continued doing work (in vain) for another 527 seconds before reaching tpreturn(), where it wrote timing information for txrpt and tried to return a response to the client that already had given up all hope.
    Does this make any sense to you?
    Best regards,
    /Per

Maybe you are looking for