SALESPERSONS COMMISSIONS PROCESS

Hai Friends
I would request to provide information on  SALESPERSONS COMMISSIONS PROCESS  in SAP SD .
1. What are the IMG Settings needed.
2. What are the master data , I have to create .
3. Without implementing HR module , Can I configure  SALESPERSONS COMMISSIONS PROCESS in SD .
Regards
Jayapala S.H

Dear,
       In our company we have develop the report for salesperson commision in SAP. So contact your ABAP developer...
Regards,
Sandip Shaktavat

Similar Messages

  • Transactional triggers and commit processing

    I have only been an active member of this thread for a couple of weeks and have tried to contribute to a few postings. But I have also noticed lots of postings relating to the use of DML statements inside what I would call non commit time triggers.
    What I mean here is, for example, a WHEN-BUTTON-PRESSED trigger that does inserts, updates, deletes, followed by the COMMIT_FORM procedure.
    I thought it might be useful to draw attention to the possible pitfalls of this approach. I'm not saying that this approach is wrong - far from it, but sometimes it means that people aren't leveraging the functionality that you get "for free" from Forms.
    By coding some DML followed by a Commit_Form, you are not getting any rollback functionality from Forms. For example:
    INSERT INTO A
    INSERT INTO B
    COMMIT_FORM;
    Let's imagine that the insert into A worked but the insert into B failed for some reason. The user gets an unhandled exception. Now imagine that the cause of the error is cleared up, and the user presses the button (or whatever the invokation action was) again, and the commit works. You will have 2 records in A and 1 in B. You may not have expected that, and without coding your own rollback/savepoint that's what you would get.
    You also (1) don't get a Working... message without coding it yourself, and (2) get the "No changes to commit" message; removing this is the subject of many threads on this site.
    If you have a block which is based over a table which you need to update, then all of the DML statements ought to be coded inside PRE/POST/ON INSERT/UDPATE/DELETE statements, or other Forms transactional triggers (pre-database-commit etc..). If you need to change other tables then put the DML for them inside those triggers. Then you don’t have to worry about which records the user changed – if the user didn’t touch them then Forms won’t fire the triggers. And when you call the COMMIT_FORM procedure, Forms will fire the triggers for you and if any of them fail, it will rollback back to where the COMMIT_FORM started.
    An example in 1 thread I saw this morning, was a Delete button, which was to delete the current record in a multi-record block. This button performed the “DELETE FROM <table> WHERE <key=:block.key>” followed by a Commit. Then of course the block needed to be re-queried to reflect the fact that the record had gone. Using the power of Forms to simply call the DELETE_RECORD procedure would have achieved the same result without needing to requery the block. And Forms would do the delete by ROWID, the fastest way of doing it.
    If you don’t have a block based over a table, then you can consider creating a dummy block which uses Transactional Triggers. Code an ON-INSERT on that block which includes the DML you want to execute. Then in the trigger initiating the commit processing you would do something like:
    :DUMMY_BLOCK.ITEM1 := ‘X’;
    COMMIT_FORM;
    IF (NOT FORM_SUCCESS) OR :SYSTEM.FORM_STATUS != ‘QUERY’ THEN
    -- the commit failed
    END IF;
    Then you’ll get a nice Working.. message and full rollback control.
    I think the moral of what I’m trying to get across is to use the power of Forms in the way it handles the transactions. Whilst we moan about it, it is actually quite good at that!
    I hope this posting is taken in a positive light, I am certainly not trying to teach anyone to “suck eggs”.
    PS. I find it ironic that you were prevented from coding DML statements outside of commit time triggers, in Forms 2.3!

    Thank you, Kevin. Very informative.

  • Commit processing in Forms 10g, what triggers fire etc.

    In the oracle documentation there used to be a commit processing flowchart that said exactly what triggers fire on commit. Don’t seem to be able to find such a thing online.
    This started by trying to work out if when-validate-item always fired on commit, even if it had been fired when the value was changes. It has turned into a more general question about the above and if it is any different in forms 10g and is it any different to 6i, 9i...?
    I.e. how do you answer the standard oracle job interview question 'what triggers are fired when you commit in forms?'.
    Oracle seems to of hidden the information, anyone know the answer?
    Regards,
    Ben

    Hello,
    Something like this:
    POST-TEXT-ITEM
    POST-RECORD
    POST-BLOCK
    PRE-COMMIT
    PRE-UPDATE
    ON-UPDATE
    POST-UPDATE
    PRE-INSERT
    ON-INSERT
    POST-INSERT
    POST-FORM-COMMIT
    ON-COMMIT
    POST-DATABASE-COMMIT
    PRE-BLOCK
    PRE-RECORD
    PRE-TEXT-ITEM
    WHEN-NEW-ITEM-INSTANCE
    Francois

  • Transaction BEA1-2CC7F743D067E50C6CCB cannot complete commit processing because resource [SOADataSource_soa_domain] is unavailable

    Hi All,
    When I started admin server I was told the SOAdatasource (one of the datasources usual for SOA), global transaction protocol should be modified from 'one-phase Commit' to either 'Logging Last Resource'' or 'Emulate Two-Phase Commit'.SO I just went to below screen and changed (Supports Global Transactions checkbioc is already checked when I went there) radio box option from 'one-phase commit' to 'Logging Last Resource'
    After I changed ,I clicked on save button on the same page.I got the message like 'your property got changed,but one item restart is neccessary' .I thought I need to restart the server.
    So I again restarted the admin server and After that when I am started the SOA server, I am getting below  error:
    Jan 20, 2014 1:27:16 PM BRST> <Warning> <JTA> <BEA-110486> <Transaction BEA1-2CC7F743D067E50C6CCB cannot complete commit processing because resource [SOADataSource_soa_domain] is unavailabl
    e. The transaction will be abandoned after 78,780 seconds unless all resources acknowledge the commit decision.>
    <Jan 20, 2014 1:28:16 PM BRST> <Warning> <JTA> <BEA-110486> <Transaction BEA1-2CC7F743D067E50C6CCB cannot complete commit processing because resource [SOADataSource_soa_domain] is unavailabl
    e. The transaction will be abandoned after 78,720 seconds unless all resources acknowledge the commit decision.>
    I also tried to change that option to Emulate Two-Phase Commit.It is the same error I am geting for that option also.
    I don't have any idea why it is happening.I think that error indiactes that the saved property info is not reached to other components in the same server.
    In this same oracle forums, somebody told the below process :
    1_ Stop your server.
    2. Go to [your domain]\servers\AdminServer\data\store\default.
    3. WLSADMINSERVER_[random number].DAT
    4. Restart server
    I did the samething ,but it is still showing same error.
    Please guide me how to resolve this issue.I think there is some problem with what to restart after I change the option of transaction protocol.
    Please help me out in this issue

    Hi:
    try placing the jars that represent ur driver, here
    For both Windows and Linux, you must perform the following steps:
    Drop the vendor-specific driver JAR files to the user_projects/domains/soainfra/lib directory.
    Drop the vendor-specific driver JAR files to the <Weblogic_Home>/server/lib.
    Edit the classpath to include the vendor-specific jar file in <Weblogic_HOME>/common/bin/commEnv.sh
    This info was copied, from here: http://docs.oracle.com/cd/E21764_01/integration.1111/e10231/adptr_db.htm#CHDBEJDC
    Hope this helps
    best

  • Help : commit processing

    Hello,
    I want to change the commit precosess, so
    when forms will save items into database,
    I want it to skip one item and do not save it even if it has receive a value!!!!!!
    I think that I have to use a key-commit trigger,
    but how can I prevent the comit of the item!!!
    Thanks for help

    Ino, Steve
    I agree with both of you.
    Jina
    (1) Your first question was
    I want forms to commit this item when it's value is :X
    and do not when it's != X!!!This means you didn’t want forms to commit only this particular item. There was no mention about the database trigger there !!! Meaning you had issue only with commit of that particular item.
    (2) Your second statement was
    I don't want want forms to take consideration of this item
    when commit processing is done because I have a database trigger that I don't want it to >execute when the value of this item ='X'When you say "you don’t want forms to take consideration of this item when commit processing is done" it means that you want form to ignore the item and not commit it but at the same time commit others.
    Is your issue the firing of trigger or the commit of that particular item or BOTH ??
    (3) Anyway this is my understanding of your issue :
    (a) If you are accessing the table from your forms application and the value of a particular item is 'X' then you don’t want the database trigger on that table to fire at all.
    (b) If you are accessing the table from your forms application and the value is !='X' then the normal processing should continue and the database trigger should fire as usual.
    (c) If you are accessing the table from any other applications, irrespective of value of that item, the normal processing should continue and the database trigger should fire as usual.
    Assuming your database trigger fires before insert or update on that table, and above conditions (a),(b),(c) are true, then you could create an extra column in the base table which acts like a flag. You could set the flag column value to lets say 1 from your forms application. Set it to lets say 2 from other applications.
    In the trigger solution given by Ino you could make following changes
    IF :new.flag = 1 AND :new.item = 'X' THEN
    -- no changes. The trigger shall still be fired, but whatever code in the trigger shall not execute.
    NULL;
    ELSE
    -- do something ... Whatever you want the trigger to do
    END IF;
    REMEMBER here that if that item is a database table item then it shall still be committed, with whatever value it holds, like the other items. If you don’t want the item to commit, Ino gave you the solution. Make it a non-database item. Then if the value is correct and you want to commit the item, in pre-insert trigger assign the value to a non-display item that represents the database column. If the column is non mandatory and the application does not supply any value for it, then
    (1) The column's default value as specified when the table was created is inserted or updated
    (2) If no default value was specified, then a null value.
    If your database trigger is different, then the solution might differ. In that case post a reply along with the database trigger.
    Regards
    Poorvi Solanki

  • Javax.transaction.SystemException: Timeout during commit processing

              In my Workshop 8.1 SP2 project I have a Custom Java Control whose methods I call
              from my JPF. From that custom control I create a remote connection to a Weblogic
              6.1 Application server. I execute remote methods and get the expected objects
              back with no problem. The problem is that I cannot return that object from my
              custom control back to my jpf. As soon as the method's return statement is executed,
              the process hangs for a considerable period of time and then throws the following
              Exception:
              An error has occurred:
              Exception while commiting Tx : Name=[EJB com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)],Xid=BEA1-0005BF0F3E6E72419698(655489),Status=Unknown,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
              since begin=217,seconds left=42983,XAServerResourceInfo[BMResourceManager]=(ServerResourceInfo[BMResourceManager]=(state=new,assigned=none),xar=null),SCInfo[midway+cgServer]=(state=active),SCInfo[prdsdomain+prdsserver]=(state=active),properties=({weblogic.transaction.name=[EJB
              com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=cgServer+172.23.83.174:7001+midway+t3+,
              XAResources={},NonXAResources={})],CoordinatorURL=prdsserver+172.23.4.109:7041+prdsdomain+t3+);
              nested exception is:
              javax.transaction.SystemException: Timeout during commit processing
              Start server side stack trace:
              javax.transaction.SystemException: Timeout during commit processing
              at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:243)
              at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:189)
              at weblogic.transaction.internal.CoordinatorImpl.commit(CoordinatorImpl.java:68)
              at weblogic.transaction.internal.CoordinatorImpl_WLSkel.invoke(Unknown Source)
              at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
              at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274)
              at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:22)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              End server side stack trace
              caused by: : javax.transaction.SystemException: Timeout during commit processing
              Start server side stack trace:
              javax.transaction.SystemException: Timeout during commit processing
              at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:243)
              at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:189)
              at weblogic.transaction.internal.CoordinatorImpl.commit(CoordinatorImpl.java:68)
              at weblogic.transaction.internal.CoordinatorImpl_WLSkel.invoke(Unknown Source)
              at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
              at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274)
              at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:22)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              End server side stack trace
              As soon as I take out RMI calls from my custom control's code, I can return any
              object I want back to my JPF. Here is the what I am thinking is happenning.
              The system that runs on Weblogic 6.1 manages its own transactions and begins a
              new transaction every time a session bean residing on that server is invoked.
              In addition, Weblogic 8.1 starts an internal transaction when the Custom Java
              Control makes a call. Could there be some kind conflict? If yes, is it possible
              to disable transactions from the Java Control?
              Thank you very much
              Alex Mayzlin
              

    Horst,
              "aa aa" <[email protected]> wrote in message news:20701457.1093414960276.JavaMail.root@jserv5...
              > we are getting the same Exception. As nobody replied to your question, it would be interesting, if you found any solution
              yourself?
              >
              > Additional info:
              > We are also getting these error messages from BEA when testing connections in pool before and after the exception:
              >
              > <20.08.2004 19.32 Uhr CEST> <Error> <JDBC> <BEA-001112> <Test "SELECT count(*) FROM invoice" set up for pool "ABCConnection Pool"
              failed with exception: "java.sql.SQLException: ORA-01591: lock held by in-doubt distributed transaction 4.47.141655".>
              Generally it's a good idea to use Oracle's system DUAL table
              for testing connections on reserve. Try to change your ABCConnection
              connection pool configuration to use DUAL as the test table
              instead of "invoice".
              Regards,
              Slava Imeshev
              

  • Timeout during commit processing

    Hi All,
    I am facing time out exception on test environment. It is clustered environment with 2 nodes. I have set trust domain between the two weblogic domains.
    In one of my EJB method having tranaction attrbiute set as Required. In this method I also make a remote ejb call to different system for which I have set Trust.
    When i execute this method , I see all my debug statement entering the method and exiting the method, after it exits my method , my client still waiting on response from this method and finally he get the java.rmi.RemoteException.
    Detailed exception as below....
    java.rmi.RemoteException: EJB Exception: ; nested exception is:
         com.bea.control.ServiceControlException: <xml-fragment xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"> <faultcode> SOAP-ENV:Client </faultcode> <faultstring> Exception while commiting Tx : Name=[EJB com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)],Xid=BEA1-0074571ED882A67DA1E5(11375621),Status=Committing,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=118,seconds left=2,XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=committed,assigned=NodeOne),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@190af6,re-Registered = false),SCInfo[p2pDomain+NodeOne]=(state=committed),SCInfo[mycompany+NodeOne]=(state=committing),properties=({weblogic.transaction.name=[EJB com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)], weblogic.jdbc=t3://192.168.86.61:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=NodeOne+192.168.86.61:7001+p2pDomain+t3+, XAResources={},NonXAResources={})],CoordinatorURL=NodeOne+192.168.86.61:7001+p2pDomain+t3+); nested exception is:
         javax.transaction.SystemException: Timeout during commit processing </faultstring> <detail>
    Exception while commiting Tx : Name=[EJB com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)],Xid=BEA1-0074571ED882A67DA1E5(11375621),Status=Committing,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=118,seconds left=2,XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=committed,assigned=NodeOne),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@190af6,re-Registered = false),SCInfo[p2pDomain+NodeOne]=(state=committed),SCInfo[mycompany+NodeOne]=(state=committing),properties=({weblogic.transaction.name=[EJB com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)], weblogic.jdbc=t3://192.168.86.61:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=NodeOne+192.168.86.61:7001+p2pDomain+t3+, XAResources={},NonXAResources={})],CoordinatorURL=NodeOne+192.168.86.61:7001+p2pDomain+t3+); nested exception is:
         javax.transaction.SystemException: Timeout during commit processing </detail></xml-fragment>
         at weblogic.ejb20.internal.EJBRuntimeUtils.throwRemoteException(EJBRuntimeUtils.java:102)
         at weblogic.ejb20.internal.BaseEJBHome.handleSystemException(BaseEJBHome.java:307)
         at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:263)
         at weblogic.ejb20.internal.StatelessEJBObject.postInvoke(StatelessEJBObject.java:140)
         at com.bea.wlw.runtime.core.bean.SyncDispatcher_k1mrl8_EOImpl.invoke(SyncDispatcher_k1mrl8_EOImpl.java:56)
         at com.bea.wlw.runtime.core.dispatcher.Dispatcher.remoteDispatch(Dispatcher.java:161)
         at com.bea.wlw.runtime.core.dispatcher.ServiceHandleImpl.invoke(ServiceHandleImpl.java:436)
         at com.bea.wlw.runtime.core.dispatcher.WlwProxyImpl._invoke(WlwProxyImpl.java:326)
         at com.bea.wlw.runtime.core.dispatcher.WlwProxyImpl.invoke(WlwProxyImpl.java:315)
         at $Proxy17.updatePurchaseOrder(Unknown Source)
         at newpageflow1.Newpageflow1Controller.begin(Newpageflow1Controller.jpf:75)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:324)
         at com.bea.wlw.netui.pageflow.FlowController.invokeActionMethod(FlowController.java:1519)
         at com.bea.wlw.netui.pageflow.FlowController.getActionMethodForward(FlowController.java:1445)
         at com.bea.wlw.netui.pageflow.FlowController.internalExecute(FlowController.java:776)
         at com.bea.wlw.netui.pageflow.PageFlowController.internalExecute(PageFlowController.java:211)
         at com.bea.wlw.netui.pageflow.FlowController.execute(FlowController.java:606)
         at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
         at com.bea.wlw.netui.pageflow.PageFlowRequestProcessor.processActionPerform(PageFlowRequestProcessor.java:1354)
         at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
         at com.bea.wlw.netui.pageflow.PageFlowRequestProcessor.process(PageFlowRequestProcessor.java:650)
         at com.bea.wlw.netui.pageflow.AutoRegisterActionServlet.process(AutoRegisterActionServlet.java:527)
         at com.bea.wlw.netui.pageflow.PageFlowActionServlet.process(PageFlowActionServlet.java:152)
         at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1006)
         at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:419)
         at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
         at com.bea.p13n.servlets.PortalServletFilter.doFilter(PortalServletFilter.java:293)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
         at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:326)
         at com.bea.wlw.netui.pageflow.PageFlowRequestProcessor.superForward(PageFlowRequestProcessor.java:1301)
         at com.bea.wlw.netui.pageflow.PageFlowRequestProcessor$DefaultHttpRedirector.forward(PageFlowRequestProcessor.java:1317)
         at com.bea.wlw.netui.pageflow.PageFlowRequestProcessor.doForward(PageFlowRequestProcessor.java:1199)
         at com.bea.wlw.netui.pageflow.PageFlowRequestProcessor.process(PageFlowRequestProcessor.java:637)
         at com.bea.wlw.netui.pageflow.AutoRegisterActionServlet.process(AutoRegisterActionServlet.java:527)
         at com.bea.wlw.netui.pageflow.PageFlowActionServlet.process(PageFlowActionServlet.java:152)
         at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1006)
         at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:419)
         at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
         at com.bea.p13n.servlets.PortalServletFilter.doFilter(PortalServletFilter.java:293)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6724)
         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
         at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
         at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3764)
         at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2644)
         at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
         at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
    Caused by: com.bea.control.ServiceControlException: <xml-fragment xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"> <faultcode> SOAP-ENV:Client </faultcode> <faultstring> Exception while commiting Tx : Name=[EJB com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)],Xid=BEA1-0074571ED882A67DA1E5(11375621),Status=Committing,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=118,seconds left=2,XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=committed,assigned=NodeOne),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@190af6,re-Registered = false),SCInfo[p2pDomain+NodeOne]=(state=committed),SCInfo[mycompany+NodeOne]=(state=committing),properties=({weblogic.transaction.name=[EJB com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)], weblogic.jdbc=t3://192.168.86.61:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=NodeOne+192.168.86.61:7001+p2pDomain+t3+, XAResources={},NonXAResources={})],CoordinatorURL=NodeOne+192.168.86.61:7001+p2pDomain+t3+); nested exception is:
         javax.transaction.SystemException: Timeout during commit processing </faultstring> <detail>
    Exception while commiting Tx : Name=[EJB com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)],Xid=BEA1-0074571ED882A67DA1E5(11375621),Status=Committing,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=118,seconds left=2,XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=committed,assigned=NodeOne),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@190af6,re-Registered = false),SCInfo[p2pDomain+NodeOne]=(state=committed),SCInfo[mycompany+NodeOne]=(state=committing),properties=({weblogic.transaction.name=[EJB com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(com.bea.wlw.runtime.core.request.Request)], weblogic.jdbc=t3://192.168.86.61:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=NodeOne+192.168.86.61:7001+p2pDomain+t3+, XAResources={},NonXAResources={})],CoordinatorURL=NodeOne+192.168.86.61:7001+p2pDomain+t3+); nested exception is:
         javax.transaction.SystemException: Timeout during commit processing </detail></xml-fragment>
         at com.bea.wlw.runtime.core.control.ServiceControlImpl.invoke(ServiceControlImpl.jcs:1233)
         at com.bea.wlw.runtime.core.dispatcher.DispMethod.invoke(DispMethod.java:377)
         at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:423)
         at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:396)
         at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:248)
         at com.bea.wlw.runtime.jcs.container.JcsContainer.invoke(JcsContainer.java:85)
         at com.bea.wlw.runtime.core.bean.BaseContainerBean.invokeBase(BaseContainerBean.java:224)
         at com.bea.wlw.runtime.core.bean.SLSBContainerBean.invoke(SLSBContainerBean.java:103)
         at com.bea.wlwgen.StatelessContainer_ly05hg_ELOImpl.invoke(StatelessContainer_ly05hg_ELOImpl.java:99)
         at com.bea.wlwgen.GenericStatelessSLSBContAdpt.invokeOnBean(GenericStatelessSLSBContAdpt.java:62)
         at com.bea.wlw.runtime.core.bean.BaseDispatcherBean.runAsInvoke(BaseDispatcherBean.java:153)
         at com.bea.wlw.runtime.core.bean.BaseDispatcherBean.invoke(BaseDispatcherBean.java:54)
         at com.bea.wlw.runtime.core.bean.SyncDispatcherBean.invoke(SyncDispatcherBean.java:168)
         at com.bea.wlw.runtime.core.bean.SyncDispatcher_k1mrl8_EOImpl.invoke(SyncDispatcher_k1mrl8_EOImpl.java:46)
         ... 53 more
    appreciated any help on this .....
    hitesh

    Hi skrai,
              From the moment the begin call is made, the timer starts ticking independently of the flow of your processing. When the timeout expires, the Transaction Manager will roll the transaction back. The first you hear of that happening may be when calls you make in the thread associated with the transaction start to throw exceptions, since it is not possible to propagate a rolled-back transaction (what would be the point, the results of the call will not persist under any circumstances?).
              Therefore suspending a transaction has no impact whatsoever on its timeout; it simply breaks the association between transaction and thread. If your code suspends a transaction and then goes to sleep for a week, it should expect to find that the transaction has timed out while it slept.
              So when U invoke an EJB with "NotSupported" tx attribute, the clock with the tx manager is still ticking.
              Hope my explanation helped to resolve your issue.
              Thanks
              -Rais

  • Where to put the commit in the FORALL BULK COLLECT LOOP

    Hi,
    Have the following LOOP code using FORALL and bulk collect, but didnt know where to put the
    'commit' :
    open f_viewed;
    LOOP
    fetch f_viewed bulk collect into f_viewed_rec LIMIT 2000;
    forall i in 1..f_viewed_rec.count
    insert into jwoodman.jw_job_history_112300
    values f_viewed_rec(i);
    --commit; [Can I put this 'commit' here? - Jenny]
    EXIT when f_viewed%NOTFOUND;
    END LOOP;
    commit;
    Thanks,
    - Jenny

    mc**** wrote:
    Bulk collect normally used with large data sets. If you have less dataset such as 1000-2000 records then you canot get such a performance improvent using bulk collect.(Please see oracle documents for this)
    When you update records Oracle acquire exclusive lock for that. So if you use commit inside the loop then it will process number of records defined by limit parameter at ones and then commit those changes.
    That will release all locks acquired by Oracle and also teh memory used to keep those uncommited transactions.
    If you use commit outside the loop,
    Just assume that you insert 100,000 records, all those records will store in oracle memory and it will affect all other users performance as well.
    Further more if you update 100,000 records then it will hold exclusive lock for all 100,000 records addtion to the usage of the oracle memory.
    I am using this for telco application which we process over 30 million complex records (one row has 234 columns).
    When we work with large data sets we do not depends with the oracle basic rollback function. because when you keep records without commit itb uses oracle memory and badly slowdown all other processes.Hi mc****,
    What a load of dangerous and inaccurate rubbish to be telling a new Oracle developer. Commit processing should be driven by the logical unit of a transaction. This should hold true whether that transaction involves a few rows or millions. If, and only if, the transaction is so large that it affects the size constraints of the database resources, in particular, rollback or redo space, then you can consider breaking that transaction up to smaller transactions.
    Why is frequent committing undesirable I hear you ask?
    First of all it is hugely wasteful of rollback or redo space. This is because while the database is capable of locking at a row level, redo is written at a block level, which means that if you update, delete or insert a million rows and commit after each individual statement, then that is a million blocks that need to go into redo. As many of these rows will be in the same block, if you instead do these as one transaction, then the same block in redo can be transacted upon, making the operation more efficient. True, locks will be held for longer, but if this is new data being done in batches then users will rarely be inconvenienced. If locking is a problem then I would suggest that you should be looking at how you are doing your processing.
    Secondly, committing brings into play one of the major serialization points in the database, log sync. When a transaction is committed, the log buffer needs to be written to disc. This occurs serially for multiple commits. Each commit has to wait until the commit before has completed. This becomes even more of a bottleneck if you are using Data Guard in SYNC mode, as the commit cycle does not complete until the remote log is notified as written.
    This then brings us two rules of thumb that will always lead a developer in the right direction.
    1. Commit as infrequently as possible, usually at the logical unit of a transaction
    2. When building transactions, first of all seek to do it using straight SQL (CTAS, insert select, update where etc). If this can't be easily achieved, then use PL/SQL bulk operations.
    Regards
    Andre

  • Commit after a select query

    Do we need to commit after a select statement in any case (in any transaction mode)?
    Why do we need to commit after selecting from a table from another databse using a DB link?
    If I execute a SQL query, does it really start a transaction in the database?
    I could not find any entry in v$transaction after executing a select statement which implies no transactions are started.
    Regards,
    Sandeep

    Welcome to the forum!
    >
    Do we need to commit after a select statement in any case (in any transaction mode)?
    >
    Yes you need to issue COMMIT or ROLLBACK but only if you issue a 'SELECT .... FOR UPDATE' because that locks the rows selected and they will remain locked until released. Other sessions trying to update one of your locked rows will hang until released or will get
    >
    ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired
    >
    In DB2 a SELECT will create share locks on the rows and updates of those rows by other sessions could be blocked by the share locks. So there the custom is to COMMIT or ROLLBACK after a select.
    >
    Why do we need to commit after selecting from a table from another databse using a DB link
    >
    See Hooper's explanation of this at http://hoopercharles.wordpress.com/2010/01/27/neat-tricks/
    And see the 'Remote PL/SQL section of this - http://psoug.org/reference/db_link.html
    A quote from it
    >
    Why does it seem that a SELECT over a db_link requires a commit after execution ?
    Because it does! When Oracle performs a distributed SQL statement Oracle reserves an entry in the rollback segment area for the two-phase commit processing. This entry is held until the SQL statement is committed even if the SQL statement is a query.
    If the application code fails to issue a commit after the remote or distributed select statement then the rollback segment entry is not released. If the program stays connected to Oracle but goes inactive for a significant period of time (such as a daemon, wait for alert, wait for mailbox entry, etc...) then when Oracle needs to wrap around and reuse the extent, Oracle has to extend the rollback segment because the remote transaction is still holding its extent. This can result in the rollback segments extending to either their maximum extent limit or consuming all free space in the rbs tablespace even where there are no large transactions in the application. When the rollback segment tablespace is created using extendable files then the files can end up growing well beyond any reasonable size necessary to support the transaction load of the database. Developers are often unaware of the need to commit distributed queries and as a result often create distributed applications that cause, experience, or contribute to rollback segment related problems like ORA-01650 (unable to extend rollback). The requirement to commit distributed SQL exists even with automated undo management available with version 9 and newer. If the segment is busy with an uncommitted distributed transaction Oracle will either have to create a new undo segment to hold new transactions or extend an existing one. Eventually undo space could be exhausted, but prior to this it is likely that data would have to be discarded before the undo_retention period has expired.
    Note that per the Distributed manual that a remote SQL statement is one that references all its objects at a remote database so that the statement is sent to this site to be processed and only the result is returned to the submitting instance, while a distributed transaction is one that references objects at multiple databases. For the purposes of this FAQ there is no difference, as both need to commit after issuing any form of distributed query.

  • Oracle post failover transaction commit error

    I have a problem on trasaction after database failover.
    Solaris 8, WLS 6.1 sp3, Oracle 8.1.7 (2 Oracle instances, one is primary and
    another is standby), JDK 1.3.1
    We found this problem in Oracle (Net 8 connection time) failover test.
    Here is what we did.
    During the load, we shut down the primary Oracle server (box).
    All in-flight transactions were wrong, this is ok.
    When new requests came in, WebLogic begin to refresh the connections.
    Because the primary Oracle server was down, it took about 70 seconds to
    refresh a connection (due to the socket timeout value) and redirect to the
    standby Oracle. This is fine.
    After a while, all connections were refreshed and all connected to the
    standby serever.
    When I opened WebLogic console to monitor the in-flight transaction, I found
    some transactions are doing committing and never finished.
    At this time most of the transaction can go through but few of them through
    an exception (attached at the end). This error could never gone although the
    frequency was not high. The strange thing is I checked the database, the
    data was committed.
    I've tried Oracle OCI driver and thin driver, both had this problem. Is
    there anyone can help me on that?
    Thanks,
    Wenji
    <Jan 28, 2003 1:49:57 PM EST> <Error> <EJB> <Exception during commit of
    transaction Name=[EJB
    com.bankframe.bp.retail.solutionset.impl.customersearch.CustomerSearchSessio
    nBean.processDataPacket(com.bankframe.bo.DataPacket)],Xid=28502:685f84a9ba5b
    1ed8(192232),Status=Committing,numRepliesOwedMe=0,numRepliesOwedOthers=0,sec
    onds since begin=122,seconds
    left=60,ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assign
    ed=prod-srv2),SCInfo[prod+prod-srv2]=(state=pre-prepared),properties=({weblo
    gic.transaction.name=[EJB
    com.bankframe.bp.retail.solutionset.impl.customersearch.CustomerSearchSessio
    nBean.processDataPacket(com.bankframe.bo.DataPacket)],
    weblogic.jdbc=t3://10.161.46.31:7101}),OwnerTransactionManager=ServerTM[Serv
    erCoordinatorDescriptor=(CoordinatorURL=prod-srv2+10.161.46.31:7101+prod+, R
    esources={})],CoordinatorURL=prod-srv2+10.161.46.31:7101+prod+):
    javax.transaction.SystemException: Timeout during commit processing
    at
    weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTra
    nsactionImpl.java:243)
    at
    weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransaction
    Impl.java:189)
    at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:272)
    at

    Wenji Tong wrote:
    Thanks, Joe!
    Things could be more complicate. I did some tests to find the details of the
    problem. Here are the results.Hi,
    This is developing into a bigger problem than I can solve informally in newsgroups,
    so I suggest that you open an official support case with this information.
    Joe
    >
    >
    1. I've done a test. In this test, I shut down the Oracle and also stop the
    load. After all threads and connection returned to the pool and all
    transactions done (roll back or abandoned), I started load again. I still
    could find this error. That means this error is not related to any in-flight
    transactions.
    2. After all connectioin failed over, this error was still not gone. The
    frequency was not high, but it was always there.
    3. In WebLogic console, monitor in-flight transaction, I saw some
    transactions were doing committing, but never finished if there was no load.
    When I saw an error printed in log, one of the committing transaction gone
    but there came out another transaction doing the commit and can't be
    finished. I'm not sure if it was related to WebLogic console's bug.
    4. Increase the transaction timeout can fix this problem. Unfortunately, we
    can't increase the transaction timeout anymore due to our business
    requirements.
    I hope those information will be helpful.
    Thanks,
    Wenji
    "Joseph Weinstein" <[email protected]> wrote in message
    news:[email protected]...
    Wenji Tong wrote:
    I have a problem on trasaction after database failover.
    Solaris 8, WLS 6.1 sp3, Oracle 8.1.7 (2 Oracle instances, one is primary
    and
    another is standby), JDK 1.3.1
    We found this problem in Oracle (Net 8 connection time) failover test.
    Here is what we did.
    During the load, we shut down the primary Oracle server (box).
    All in-flight transactions were wrong, this is ok.
    When new requests came in, WebLogic begin to refresh the connections.
    Because the primary Oracle server was down, it took about 70 seconds to
    refresh a connection (due to the socket timeout value) and redirect tothe
    standby Oracle. This is fine.
    After a while, all connections were refreshed and all connected to the
    standby serever.
    When I opened WebLogic console to monitor the in-flight transaction, Ifound
    some transactions are doing committing and never finished.
    At this time most of the transaction can go through but few of themthrough
    an exception (attached at the end). This error could never gone althoughthe
    frequency was not high. The strange thing is I checked the database, the
    data was committed.
    I've tried Oracle OCI driver and thin driver, both had this problem. Is
    there anyone can help me on that?
    Thanks,
    WenjiHi. It seems that Oracle failover is not perfect. Our transactioncoordinator
    is supposed to have control of the transaction. If a failover occurs while
    a transaction is pending, the coordinator should still have the ability toroll
    back the tx. Apparently there are cases where the failover causes an open
    transaction to be committed, in such a way that even if the coordinatorhas
    decided to roll it back, it can't. These may be when the failover occurswhile
    we are waiting for the commit call to return. We either get an exceptionor
    we get no return from the commit() call so we try to roll back and fail.The
    actual commit succeeded, but we never knew.
    Joe
    <Jan 28, 2003 1:49:57 PM EST> <Error> <EJB> <Exception during commit of
    transaction Name=[EJB
    com.bankframe.bp.retail.solutionset.impl.customersearch.CustomerSearchSessio
    >nBean.processDataPacket(com.bankframe.bo.DataPacket)],Xid=28502:685f84a9ba5b
    >1ed8(192232),Status=Committing,numRepliesOwedMe=0,numRepliesOwedOthers=0,sec
    onds since begin=122,seconds
    left=60,ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assign
    >ed=prod-srv2),SCInfo[prod+prod-srv2]=(state=pre-prepared),properties=({weblo
    gic.transaction.name=[EJB
    com.bankframe.bp.retail.solutionset.impl.customersearch.CustomerSearchSessio
    nBean.processDataPacket(com.bankframe.bo.DataPacket)],
    weblogic.jdbc=t3://10.161.46.31:7101}),OwnerTransactionManager=ServerTM[Serv
    >erCoordinatorDescriptor=(CoordinatorURL=prod-srv2+10.161.46.31:7101+prod+, R
    esources={})],CoordinatorURL=prod-srv2+10.161.46.31:7101+prod+):
    javax.transaction.SystemException: Timeout during commit processing
    at
    weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTra
    nsactionImpl.java:243)
    at
    weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransaction
    Impl.java:189)
    atweblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:272)
    at

  • Perform on commit

    Hi,
    can you show me an example of "perform on commit" with variables.

    Hi,
    PERFORM ON COMMIT routines are not executed in the dialog module.
    You must ensure that any subroutines called using ON COMMIT can be delayed until the next COMMIT WORK in the calling program. Remember that the global data of the dialog module is destroyed along with the internal session when control returns to the calling program. Consequently, subroutines called using PERFORM ON COMMIT must not use this global data.
    The statement PERFORM ON COMMIT calls a subroutine in the dialog work process. However, it is not executed until the system reaches the next COMMIT WORK statement. Here, as well, the ABAP statement COMMIT WORK defines the end of the SAP LUW, since all statements in a subroutine called with PERFORM ON COMMIT that make database changes are executed in the
    database LUW of the corresponding dialog step.
    The advantage of this bundling technique against CALL FUNCTION... IN UPDATE TASK is better performance, since the update data does not have to be written into an extra table. The disadvantage, however, is that you cannot pass parameters in a PERFORM... ON COMMIT statement. Data is passed using global variables and ABAP memory. There is a considerable danger of data inconsistency when you use this method to pass data.
    You can also put the CALL FUNCTION IN UPDATE TASK into a subroutine and call the subroutine with:
    <b>PERFORM SUBROUT ON COMMIT.</b>
    If you choose this method, the subroutine is executed at the commit. Thus the request to run the function in the update task is also logged during commit processing. As a result, the parameter values logged with the request are those current at the time of the commit.
    Ex.
    a = 1.
    PERFORM F ON COMMIT.
    a = 2.
    PERFORM F ON COMMIT.
    a = 3.
    COMMIT WORK.
    FORM f.
    CALL FUNCTION 'UPD_FM' IN UPDATE TASK EXPORTING PAR = A.
    ENDFORM.
    In this example, the function module UPD_FM is carried out with the value 3 in PAR. The update task executes the function module only once, despite the two PERFORM ON COMMIT statements. This is because a given function module, logged with the same parameter values, can never be executed more than once in the update task. The subroutine itself, containing the function module call, may not have parameters.
    Regards,
    Bhaskar

  • Eclipse : Team- Commit Context Menu is inactive

    HI All,
    I have configure the Eclipse Kepler with the SAP HANA Plugins.
    And able to Connect the SAP Hana Cloud Server from the local system.
    BUt when i have created the Some Objects in Project Workspace and trying to do the Commit (To send the all objects to Cloud System).
    I am getting the inavtive form of Commit option.
    But the same I am getting in SAP HANA Studio, but after commit process I am getting the java.Lang.NullException and System is getting hang.
    Please suggest what cloud be the reason and how to resolve the same.
    Thanks & Regards.
    Praveer.

    Hi,
       Could you please help me too. I am also getting the same problem even though host is fully qualified name like aaa.bbb.ccc.net:50000/.. and referring to KM folders. Its not displaying the xml forms after pressing the hyperlink available under the km folder.
    Line : 1
    Char: 1
    Error: Object expected
    Code:0
    URL: http://aaa.bb.cc.net:50000/...
    Thank you for all your support
    Best Regards
    Jeb

  • BPM BAPI COMMIT

    Hi,
    I try to create a sync connection BPM which soap post data to BPM then inside BPM i have 2 bapi which the first bapi will need to commit by XI before process the second bapi. I have done all this and it work but there was a problem of the commit process time sometime the second bapi will return mat doc not found. I know that BPM have the wait process but the minimum time is 1 minute which is quit long for sync process. Is that any way to make the second bapi process only is the 1st bapi commit successful.
    Best Regard,
    Gan

    Hi,
    Thanks for reply. I am also consider about the performance of the BPM but the reason i am using BPM is to let the XI handle the commit for bapi. For example lets said after XI past data to bapi and then the connection between XI and SAP R3 down then the soap client cant get the data but the bapi with commit if i put the commit on z bapi. In order to control this i have to let XI control the commit.
    Is that anyway to handle this?
    Best Regard,
    GAN
    Edited by: fcgan on Dec 2, 2008 8:12 AM

  • Commit sequence

    Hi all,
    I'd like to know a little more on a DB commit process. In my database,
    Table A is parent of Table B. And Table B is parent of Table C. The following code will attempt to fill each of these table with respect to their relationship:
    class Update {
      DAOFactory mySQL = null;
      ServiceTable_A serviceA = null;
      ServiceTable_B serviceB= null
      ServiceTable_C serviceC =null;
      public Update(){
          mySQL = DAOFactory.getDAOFactory(DAOFactory.MYSQL);
         serviceA = mySQL.getServiceA();
         serviceB = mySQL.getServiceB();
         serviceC = mySQL.getServiceC();
      public void addToA(Person A){
           int status = serviceA.insert(A);
      public void addToB(Relative B){
           int status = serviceB.insert(B);
      public void addToC(Address C){
           int status = serviceC.insert(C);
      public boolean success(){
           if(status > -1){
               mySQL.commit();  //see snapshot of commit method below
          else
               mySQL.rollback();
    class PerformUpdate(){
        Update update = null;
        Person A = null;
        Relative B = null;
        Address C = null;
        public PerformUpdate(Update d){
             update= d;
        public void performNewPerson(Person A, Relative B, Address C){
              update.addToA(A);
             update.addToB(B);
             update.addToC(C);
    class View{
        private boolean UPDATE = true;
        private PerformUpdate perf = null;
       public void constructObjsFromInput(){
             // I construct Person A, Relative B, Address C objs here
       public void executeAction(){
            constructObjsFromInput();
            if(UPDATE){
                perf = new PerformUpdate(new Update());
                perf.performNewPerson(A, B, C);
      //HERE IS A SNAPSHOT OF THE COMMIT METHOD IN MYSQL FACTORY
      public void commit(){
         if( ! connection.isAutoCommit()){
                connection.commit();
                connection.setAutoCommit(true);
                      dbUtils.close(connection);  //dbUtils will close connections in
                                                                       //finally block
      }serviceA, serviceB, and serviceC have their own preparedStatements that
    executes insert commands.
    Assume that none of them fail, it's still important that serviceA commits first, followed by serviceB, then serviceC based on their relationship.
    Is there anyway that the sequence of execution triggered by the commit gets jacked up on the way to the DB ? I tested this situation several times.
    Two situations occur wih the same set of data:
    1. Table B, child of Table A, cannot be updated because of foreign key constraints. It is as if, serviceB attempted to be updated before Table A did !
    2. Table C, child of Table B, cannot be updated because of foreign key constraints. It is as if, Table A update occured first, then Table C's followed by table B.
    Are we guaranteed that preparedStmts will be committed with respect to the time they were called ?
    or does it depend the weight of their query ?
    or it's just up to the JVM to give resources to whichever one? If so, do we have a way to force the sequence to happen in one way ?
    Thanks

    also check for any key assumptions that may not be
    valid. What is the foriegn key constraint? Is it an
    autonumber that you are making an assumption about
    that when it turns out to be not what you think blows
    it all up?That's exactly right. The DB keys are auto-generated, auto-incremented.
    With this in mind, if i want to add a new field to a Table , I compute the next number sequence of the key. In that manner:
    class ServiceToTable_A implements ServiceA_DAO{
        private Connection con = null;
        public ServiceToTable_A(Connection con){
              this.con = con
        // The body structure of this method is the same for all other daos
       // except that I query the appropriate table for a given service
        public int nextSeq(int increment){
             int key = 0;
             Statement stat = null;
             ResultSet keySet = null;
              try{
                      String query= "Select * from table A";
                      stat = con.createStatement();
                      keySet = stat.executeQuery(query);
                      keySet.last();   //move cursor to last row
                      key = keySet.getInt("person_id");
              }catch(Exception n){
                   //log error             
               finally{
                  stat.close();
                  keySet.close();
              return key + inc;
       class Loading {
          DAOFactory mySQL = null;
         ServiceTable_A serviceA = null;
         ServiceTable_B serviceB= null
         ServiceTable_C serviceC =null;
         public Loading(){
               mySQL = DAOFactory.getDAOFactory(DAOFactory.MYSQL);
              serviceA = mySQL.getServiceA();
              serviceB = mySQL.getServiceB();
              serviceC = mySQL.getServiceC();
          public int getNextPersonId(int inc){
                  return serviceA.nextSeq(inc);
          public int getNextRelativeId(int inc){
                  return serviceB.nextSeq(inc);
       class View{
            Person A;
            Relative B;
            Loading load = new Loading();
            public void constructObjects(){
                      A = new Person();
                      //Construct A from input fields
                      B.setParentKey(load.getNextPersonId(1));
                      //construct B from input fields              
                      C.setParentKey(load.getNextRelativeId(1);
                //construct C from input fields              
    }As you said, i'll do some more testing to isolate what's going on. It seems very odd that the two outcomes alternate like that. Or I may just have the coolest DB on earth

  • What do you mean by commit command

    hi gurus,
      what do you mean by commit command, and how we can use in subroutines...
    regards,
    praveen

    Praveen,
    read the below  doc. very very useful one.
    Error Handling for Bundled Updates
    Runtime errors can occur during execution of bundled updates. How are they handled? In general, COMMIT WORK processing occurs in the following order:
    All dialog-task FORM routines logged with PERFORM ON COMMIT are executed.
    All high-priority (V1) update-task function modules are executed.
    The end of V1-update processing marks the end of the . If you used COMMIT WORK AND WAIT to trigger commit processing, control returns to the dialog-task program.
    All low-priority (V2) update-task function modules are triggered.
    All background-task function modules are triggered.
    Runtime errors can occur either in the system itself, or because your program issues an termination message (MESSAGE type ‘A’). Also, the ROLLBACK WORK statement automatically signals a runtime error. The system handles errors according to where they occur:
    in a FORM routine (called with PERFORM ON COMMIT)
    Updates already executed for the current update transaction are rolled back.
    No other FORM routines will be started.
    No further update-task or background-task functions will be started.
    An error message appears on the screen.
    in a V1 update-task function module (requested IN UPDATE TASK)
    Updates already executed for V1 functions are rolled back.
    All further update-task requests (V1 or V2) are thrown away.
    All background-task requests are thrown away.
    Updates already executed for FORM routines called with PERFORM ON COMMIT are not rolled back.
    An error message appears on the screen, if your system is set up to send them
    in a V2 update-task function module (requested IN UPDATE TASK)
    Updates already executed for the current V2 function are rolled back.
    All update-task requests (V2) still to be executed are discarded.
    All background-task requests still to be executed are carried out.
    No updates for previously executed V1 functions are rolled back.
    No updates previously executed for FORM routines (called with ON COMMIT) are rolled back.
    An error message appears on the screen, if your system is set up to send them
    in a background-task function module (requested IN BACKGROUND TASK DESTINATION)
    Background-task updates already executed for the current DESTINATION are not rolled back.
    All further background-task requests for the same DESTINATION are thrown away.
    Other previously executed updates are rolled back.
    No error message appears on the screen.
    If your program detects that an error in remote processing has occurred, it can decide whether to resubmit the requests at a later time.
    For further information about RFC processing, refer to the Remote Communications documentation.

Maybe you are looking for

  • Content Tab: None of the fact tables are compatible with the query request

    Hi All, **One thing I am not clear yet of all my years with OBIEE is working with the content tab in BMM.** I have made a rpd the joins in physical layer as shown below: https://picasaweb.google.com/114804305606242416264/OBIEEError#566305654511942853

  • ERROR INSTALLATION 39 ADOBE MUSE CC 2014.3

    non riesco ad installare l'aggiornamento ad adobe muse cc 2014.3 e non riesco a lavorare cosa mi esce

  • Show in explorer

    Hi I've moved my Catalog on an other hard drive. Since then the option "Show in explorer" in the Exportation doesn,t work! Thank for your help. Francois

  • How to make a 2-column output in sapscript form

    Hello Abap Professionals! I have a sample standard text that has this content and layout: Part I : This is an example only.This is an example only.This is an example only. This is an example only.This is an example only.This is an example only.This i

  • Programatically setting column values for table

    hi... I am programatically setting column values for table. But these values are not getting reflected on table after commit. I mean to say,new values are not persisted after commit. The code is as follows,It is in Application Module class public voi