Commit and rollback on session level

Hi All,
I am calling one stored procedure and I am doing some dml operation in that sp. there after I calling another sp which contain some ddl operations. if process may be fail in somewhere I wanted to rollback all dml transactions.
So I wanted to commit and rollback on session level. Is such kind of concept available in oracle.
Prashant.

Prashant,
Not sure what you are talking about.
Commit and rollback is always on session level!!!!
Also all DDL statements are automatically committed, and rollback in case of errors is always statement level rollback.
So let's assume
begin
insert into foo...;
update foo...;
execute immediate 'alter table foo add (last_update date)';
end;
exit
and the alter table fails:
1 alter table is rolled back
2 insert and updates are not rolled back.
If the alter table succeeds
all statements are committed and you can't roll them back anymore.
This is why issuing DDL in stored procedures has unwanted side effects and should be conisdered pure evil.
Sybrand Bakker
Senior Oracle DBA
Experts: those who did read the documentation.

Similar Messages

  • How to use commit and rollback transaction if my i am using MS Access as a

    as per my knowledge the transactions commit and rollback is not work if my data base is MS Access then plz give me the logic how i used these transaction with MS Access.
    waiting for response
    plz mail ur respose if possible at [email protected]

    Same as every other relational database you can connect to with JDBC.
    try
        connection.setAutoCommit(false);
         // Perform your unit of work here
         connection.commit();
    catch (SQLException e)
        connection.rollback();
         e.printStackTrace();
    finally
        try { if (connection != null) connection.close(); } catch (SQLException ignore) {}
    }%

  • How to use COMMIT and ROLLBACK in BAPIs

    Hi experts,
        Can we use COMMIT or ROLLBACK in the BAPI just like how we implement it in the ABAP programming ?? If it is yes,
        Where can we exactly use normal COMMIT and where we use BAPI_TRANSACTION_COMMIT when we are implementing BAPIs ?
    Please clarify this. Any reply is really appreciated !!
    Thank you in advance.

    Hi
    see commit is the thing which saves the changes you made to the
    database otherwise imean if u have not done the commit work what
    happens is the changes will be killed once the your program life has
    been killed i think you got why we will do commit work
    BAPI's are the methods through which we can input the data i mean it
    is an interface technique it is a direct input method.
    for example you have inserted some data into one table by using this
    BAPI technique but you not done the Commit BAPI then wht happens is
    the changes u made to the database cannot been seen in the table these
    will get effective once u have Done the Commit BAPI
    i think i am clear to u
    Rollback
    see by taking the above example only we can know wht is Rollback it is nothing but UNDO option in ms office se untill saving if we want one step back we will do it by undo option am i right similalry untill commit ing i.e. nothing until saving the changes made u can delete the modified change i.e. u can go to the stage how it was previously ok
    i think u got me
    plzz reward if i am clear to u.......
    see once u have done commit u cant rollback
    same as once  u saved one document u cant undo the document changes i think u got me
    Thanks and regards
    plzz dont forget to reward if i am useful....
    u can contact me as my details are in my business card if u want any further clarification....

  • Managing commit and rollback via XSU

    Hi there
    I am using the XSU for Java version 8.1.7. on an Oracle 8.1.7 database.
    I am managing updates on multiple tables from a single XML document, by splitting the XML into sections and calling insertXML, updateXML and deleteXML for each table requiring changes.
    I would like to know how I can manage any commits on the database, so that the whole batch may be rolled back if some data is not committed. Is there a call in the XSU to handle this, or should it be done on the JDBC connection? I have looked at the setBatchSize and setCommitBatch functions, but they seem to be dependent on the number of rows of XML being processed, and I just want to commit after all calls to the XSU have completed successfully.
    Can anyone help or enlighten me?
    TIA
    Tim McMaster

    Trouble using forums?
    Can this be solved
    Still having problems!
    Why would you want to start a new thread?
    This just makes it harder for people to help you because all of a sudden they have to
    * ask you lots of questions because you don't really provide enough info, or
    * search for the old threads and read through what happened so far.
    Have you done basic troubleshooting?
    [ like making a test table with all the same columns [b]except that infamous 'Postco' column - and test inserting into this test table? ]

  • Bean Managed Transactions and rollback

    Hi Everybody,
    I am using Bean Managed Transactions in a Message Bean which is called every some time by an EJB3 timer. This Message Bean subsequently calls a Session Bean which uses Container Managed Transactions and uses the default transaction attribute which is SUPPORTS. The Session Bean methods might sometime throw a System Exception(inheriting from RuntimeException) which will rollback the Bean Managed Transaction which was started from the Message Bean.
    When this happens and I try to invoke userTransaction.rollback() I get invalid transaction state exception and I suppose this means that is already rolled back.
    Is there a way to get another transaction or set the transaction back to a valid state so I can carry on with some persistence tasks or the only way to do that is by suppressing the RuntimeException and throwing an Application Exception having the *@ApplicationException(rollback=false)* annotation? Can I suppress a System Exception though?
    Thank you in advance!

    Saroj wrote:
    Hi All,
    I would like to know whether we can use JDBC Connection Object's commit and rollback
    methods to control Transaction in Bean Managed Transactions or not.You may use the JDBC connection's transaction support from an EJB. That being said, you
    need to understand that it won't be the transaction that started declaratively by the
    EJB container nor would it be a bean-managed transaction started through
    UserTransaction.
    FWIW, I question why you'd want to do this though. I'd use container-managed
    transactions and let the container handle this for you. The transaction manager
    includes a 1PC optimization so it's not going to do an XA/2PC tx if you only have a
    single resource in the tx. Also, the EJB container includes all the logic to properly
    handle rollbacks when exceptions are thrown etc.
    Finally, your code will more maintainable and reusable if you use the container-managed
    tx + JTA resources. If I later wanted to call another EJB or another JTA resource (eg
    JMS perhaps) I could do it without having to rewrite all of your code.
    -- Rob
    >
    >
    Why is it required that we should use Java Transaction API to control the Transaction
    in Our Beans?
    I understand that if we are using Multiple Resources and need to use Transaction
    then going for JTA makes sense. If I am using only Resource,for example, Only One
    Connection then we should be able to use Connection's Transaction control.
    I understand that other way to do the transaction is to use Container's transaction
    services.
    Please respond at the earliest.
    Thanks in Advance,
    Saroj

  • Is it possible to trap the user's COMMIT and do something?

    I need to do some actions when a user (actually a program that I can't access) performs COMMIT and close the session.
    My functionality is activated from triggers. I keep many variable in package. Before a session ends I need to do some final steps using package variables.
    I use Pl/SQL in Oracle 7.3
    Does somebody know any way to perform that?
    Thank you for any suggestion.
    null

    Layer Bounds, Look at the scripts in my Photo Collage Toolkit Package
    Documentation and Examples
    Download

  • What is Database Commit and Database Rollback.

    What is Database Commit and Database Rollback.

    Hi Sir ,
    Please have a look below .Hope it is suitable and simpler solution for your question.
    Please do reward if useful.
    Thankx.
    In database level this will be used..
    Commit is nothing but SAVE the current record..
    If u rol back before commit means whatever u proceeded for the SAVING will be roll back and the data will not be stored..
    This will be used,When some times u r filling a register form..after filling 20 fields,In the 21st field u will not to registrer means it will be rollbacked using the Rollbeck command.
    In detail--->
    ROLLBACK->
    In a ROLLBACK, all the changes made by a transaction or a subtransaction on the database instance are reversed.
    · Changes closed with a COMMIT can no longer be reversed with a ROLLBACK.
    · As a result of a ROLLBACK, a new transaction is implicitly opened.
    In normal database operation, the database system performs the required ROLLBACK actions independently. However, ROLLBACK can also be explicitly requested using appropriate SQL statements.
    In a restart, the system checks which transactions were canceled or closed with a ROLLBACK. The actions are these transactions are undone.
    COMMIT->
    In a COMMIT, all the changes made by a transaction or a subtransaction on the database instance are recorded.
    · Changes closed with a COMMIT can no longer be reversed with a ROLLBACK.
    · As a result of a COMMIT, a new transaction is implicitly opened.
    In normal database operation, the database system performs the required COMMIT actions independently. However, COMMIT can also be explicitly requested using appropriate SQL statements.
    In a restart, the system checks which transactions were closed with a COMMIT. These actions are redone. Transactions not yet closed with a COMMIT are undone.
    From the point of view of database programming, a database LUW is an inseparable sequence of database operations that ends with a database commit. The database LUW is either fully executed by the database system or not at all. Once a database LUW has been successfully executed, the database will be in a consistent state. If an error occurs within a database LUW, all of the database changes since the beginning of the database LUW are reversed. This leaves the database in the state it was in before the transaction started.
    the statements
    COMMIT WORK.
    and
    ROLLBACK WORK.
    for confirming or undoing database updates. COMMIT WORK always concludes a database LUW and starts a new one. ROLLBACK WORK always undoes all changes back to the start of the database LUW.

  • What is the use of commit work and rollback work

    hao friends,
    what is the use of commitwork and rollback work where we can use these open sql statements .
    thanks,
    anji

    hi all
    i have written the following code in my development system to change the records of my database.
    SELECT * FROM zyikostl INTO TABLE itab.
      LOOP AT itab INTO wtab.
        tabix = sy-tabix.
        DO.
          READ TABLE itab INTO ktab WITH KEY kostl_alt = wtab-kostl_neu.
          IF sy-subrc = 0.
            wtab-kostl_neu = ktab-kostl_neu.
            MODIFY itab FROM wtab INDEX tabix.
            CONTINUE.
          ELSE.
            EXIT.
          ENDIF.
        ENDDO.
      ENDLOOP.
    MODIFY zyikostl FROM TABLE itab.
    In the development system i have only few records its working fine,but when it is been moved to test system there are 2500 records in the database so the report is taking much time(more than 5 hours )
    i sthere any solution for this ....
    thanks,
    vaasu.

  • How to Use Transient View Objects to Store Session-level Global Variables

    hi
    Please consider section "40.8.5 How to Use Transient View Objects to Store Session-level Global Variables"
    at http://download.oracle.com/docs/cd/E14571_01/web.1111/b31974/bcstatemgmt.htm#ADFFD19610
    Based on this documentation I created the example application
    at http://www.consideringred.com/files/oracle/2010/ProgrammaticalViewObjectAndRollbackApp-v0.01.zip
    It behaves as show in the screencast at http://screencast.com/t/qDvSQCgpvYdd
    Its Application Module has a Transient View Object instance "MyEmployeesContextVOVI", as master for the child View Object instance "EmpInCtxJobVI".
    On rollback the Transient View Object instance keeps its row and attribute values.
    Also when passivation and activation is forced (using jbo.ampool.doampooling=false ) the Transient View Object instance seems to keep its row and attribute values.
    questions:
    - (q1) Why does the expression #{bindings.MyEmployeesContextVOVIIterator.dataControl.transactionDirty} evaluate as true when a Transient View Object instance attribute value is changed (as shown in screencast at http://screencast.com/t/qDvSQCgpvYdd )?
    - (q2) What would be a robust approach to make a Transient View Object instance more self-contained, and manage itself to have only one single row (per instance) at all times (and as such removing the dependency on the Application Module prepareSession() as documented in "5. Create an empty row in the view object when a new user begins using the application module.")?
    many thanks
    Jan Vervecken

    Thanks for your reply Frank.
    q1) Does sample 90 help ? http://blogs.oracle.com/smuenchadf/examples/
    Yes, the sample from Steve Muench does help, "90. Avoiding Dirtying the ADF Model Transaction When Transient Attributes are Set [10.1.3] "
    at http://blogs.oracle.com/smuenchadf/examples/#90
    It does point out a difference in marking transactions dirty by different layers of the framework, "... When any attribute's value is changed through an ADFM binding, the ADFM-layer transaction is marked as dirty. ...".
    This can be illustrate with a small change in the example application
    at http://www.consideringred.com/files/oracle/2010/ProgrammaticalViewObjectAndRollbackApp-v0.02.zip
    It now shows the result of both these expressions on the page ...
    #{bindings.MyEmployeesContextVOVIIterator.dataControl.transactionDirty}
    #{bindings.MyEmployeesContextVOVIIterator.dataControl.dataProvider.transaction.dirty}... where one can be true and the other false respectively.
    See also the screencast at http://screencast.com/t/k8vgNqdKgD
    Similar to the sample from Steve Muench, another modification to the example application introduces MyCustomADFBCDataControl
    at http://www.consideringred.com/files/oracle/2010/ProgrammaticalViewObjectAndRollbackApp-v0.03.zip
    public class MyCustomADFBCDataControl
      extends JUApplication
      @Override
      public void setTransactionModified()
        ApplicationModule vApplicationModule = (ApplicationModule)getDataProvider();
        Transaction vTransaction = vApplicationModule.getTransaction();
        if (vTransaction.isDirty())
          super.setTransactionModified();
    }Resulting in what seems to be more consistent/expected transaction (dirty) information,
    see also the screencast at http://screencast.com/t/756yCs1L1
    Any feedback on why the ADF Model layer is so eager to mark a transaction dirty is always welcome.
    Currently, question (q2) remains.
    regards
    Jan

  • Two phase commit and bean managed transactions

    To all the Transaction GURUS!
              Hi guys (-and gals).
              I've been doing J2EE for quite a while, but today was my first at
              XA-Transactions and Bean Managed Transactions.
              Why am I doing this?
              ====================
              Well I have to be able to controll the transactionalbehaviour of my
              bean
              during runtime, since some bean calls would cause a transactional
              overflow due to the stress they would cause to the system, whereas
              smaller bean calls need to run in one transaction.
              -> Therefore I need Bean Managed Transactions
              Since the bean does a call on two Database Connections it has to use a
              XA-Transaction.
              -> Therefore I need XA-Transactions.
              Abstract
              ========
              - I just can't get a User TransAction into the right Status it stays
              in 'STATUS_NO_TRANSACTION' all the time
              - Therefore the SQL Commands can be comitted 'java.sql.SQLException:
              Does not support SQL execution with no global transaction'
              - Therefore I can't do a rollback 'java.lang.IllegalStateException:
              Transaction does not exist'
              - Therefore I wrote this mail.
              I don't want to be a smart-"ass" writing such a detailed and indepth
              mail. I just would like to show that I tried, and would like to have
              some replies from you guys.
              Below are my configurations, code and logfiles.
              Thanx for taking your time and hope that the other people may learn
              something as well.
              cu
              Stefan
              Scenario
              ========
              used Software
              Bea Weblogic (WL) 6.0 SPx (not real sure which SP i have)
              Oracle 8.1.6 using the API-Version 8
              I configured the system as follows:
              (ofcourse I 'xxx'ed out all of the confidential data, sorry guys;-))
              excerpt from:
              config.xml
              <JDBCConnectionPool CapacityIncrement="5"
              DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="2"
              LoginDelaySeconds="1" MaxCapacity="5" Name="oraclePool"
              Properties="user=xxx;password=xxx;dll=ocijdbc8;protocol=thin"
              RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
              TestTableName="languages" URL="jdbc:oracle:thin:@xxx:1521:xxx "/>
              <!-- Since this is our Main Datasource I would not like to use a XA
              Transaction due to performance Issues
              and the TxDataSource:
              -->
              <JDBCTxDataSource EnableTwoPhaseCommit="true"
              JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
              PoolName="oraclePool" Targets="fbsserver"/>
              <!-- no comment required -I hope.
              Next comes the "special" Pool
              -->
              <JDBCConnectionPool CapacityIncrement="5"
              DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
              LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
              Properties="user=xxx;password=xxx;server=xxx.xxx.xxx"
              RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
              TestTableName="Users" SupportsLocalTransaction="true"/>
              <!-- Well since there can only be one none XARessourceManager involved
              in a 2PC
              (keyword: Two Phase Commit) I will have to use a XACapable Driver for
              the other
              Datasource. Due to all the bugs in the oracle.xxx driver. I'll be
              using the jdriver for oci.
              I activated 'SupportsLocalTransaction' hoping it would solve my
              problem - without effect. I just left in there now, since it made
              sense me. Not?
              Again the TxDataSource:
              -->
              <JDBCTxDataSource EnableTwoPhaseCommit="true"
              JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
              Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
              <!-- The System starts right up and can locate the test tables and
              everything. So I think all of this stuff is working here -->
              ejb-jar.xml
              <ejb-jar>
                   <enterprise-beans>
                        <session>
                             <ejb-name>TPCTestBean</ejb-name>
              <home>de.sitewaerts.futuna.common.test.tpcbean.TPCHome</home>
              <remote>de.sitewaerts.futuna.common.test.tpcbean.TPC</remote>
              <ejb-class>de.sitewaerts.futuna.common.test.tpcbean.TPCBean</ejb-class>
                             <session-type>Stateless</session-type>
                             <transaction-type>Bean</transaction-type>
                        </session>
                   </enterprise-beans>
                   <assembly-descriptor/>
              </ejb-jar>
              <!-- Originally I had the assembly-descriptor full of transaction
              requirements. I thought since
              the bean is handling all of the transaction stuff itself, it might get
              confused by the 'container-transaction'
              properties, and deleted them. Do I need them anyway?-->
              weblogic-ejb-jar.xml
              <weblogic-ejb-jar>
                   <weblogic-enterprise-bean>
                        <ejb-name>TPCTestBean</ejb-name>
                        <stateless-session-descriptor/>
                        <jndi-name>finstral/ejb/test_tpc</jndi-name>
                   </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              <!-- Nothing I have to explain here -->
              BeanCode (from the implementingBeanClass:
              'de.sitewaerts.futuna.common.test.tpcbean.TPCBean')
              public void setupTables() throws RemoteException
              UserTransaction tx = getTransaction();
              //getTransaction calls: 'tx = sCtx.getUserTransaction()' and does
              some errorhandling
              log.info("Die Transaktion vor den Connections: "+tx.toString());
              //Sorry bout the German. You should get the Message though.
              log.info("Der Transaktionsstatus vor den Connections:
              "+transactionStatus(tx));
              Connection conSecurity = getConnection(DATASOURCE_SECURITY, tx);
              //gets a Connection via a DataSourceName from the JNDI tree
              Connection conContent = getConnection(DATASOURCE_CONTENT, tx);
              log.info("Die frische Connection conSecurity: "+conSecurity);
              log.info("Die frische Connection conContent: "+conContent);
              tearDownTable(conSecurity);
              //Does nothing special
              tearDownTable(conContent);
              log.info("Die Transaktion nach dem Teardown: "+tx.toString());
              log.info("Der Transaktionsstatus nach dem Teardown:
              "+transactionStatus(tx));
              Statement stmt = null;
              try
              stmt = conSecurity.createStatement();
              //Well its getting interesting now.....
              log.info("Die Transaktion vor dem createtable: "+tx.toString());
              log.info("Der Transaktionsstatus vor dem createtable:
              "+transactionStatus(tx));
              log.info("Die Connection conSecurity vor dem createtable:
              "+conSecurity);
              log.info("Die Connection conContent vor dem createtable:
              "+conContent);
              stmt.executeUpdate(CREATE_TABLE);
              //above is the row 91 -> throws: 'java.sql.SQLException: Does
              not support SQL execution with no global transaction'
              stmt.close();
              stmt = conContent.createStatement();
              stmt.executeUpdate(CREATE_TABLE);
              stmt.close();
              commitTransaction(tx);
              catch (SQLException sqle)
              log.error("Konnte kein table init machen", sqle);
              rollbackTransaction(tx);
              //The Code for this method is below
              throw new EJBException(sqle);
              finally
              closeConnection(conSecurity);
              closeConnection(conContent);
              protected void rollbackTransaction(UserTransaction tx)
              log.info("Der Transaktionsstatus vor dem Rollback:
              "+transactionStatus(tx));
              log.info("Die Transaktion vor dem Rollback: "+tx.toString());
              try
              tx.rollback();
              //above is row 200 -> throws: 'java.lang.IllegalStateException:
              Transaction does not exist'
              log.info("Der Transaktionsstatus nach dem Rollback:
              "+transactionStatus(tx));
              log.info("Die Transaktion nach dem Rollback: "+tx.toString());
              catch (Exception e)
              log.error("Konnte die Transaktion nicht backrollen.", e);
              throw new EJBException(e);
              Log Excerpt
              ===========
              INFO setupTables() (66) - Die Transaktion vor den Connections:
              [email protected]
              INFO setupTables() (67) - Der Transaktionsstatus vor den Connections:
              STATUS_NO_TRANSACTION
              INFO setupTables() (72) - Die frische Connection conSecurity:
              weblogic.jdbc.rmi.SerialConnection@7c6daa
              INFO setupTables() (73) - Die frische Connection conContent:
              weblogic.jdbc.rmi.SerialConnection@3b425
              INFO setupTables() (78) - Die Transaktion nach dem Teardown:
              [email protected]
              INFO setupTables() (79) - Der Transaktionsstatus nach dem Teardown:
              STATUS_NO_TRANSACTION
              INFO setupTables() (86) - Die Transaktion vor dem createtable:
              [email protected]
              INFO setupTables() (87) - Der Transaktionsstatus vor dem createtable:
              STATUS_NO_TRANSACTION
              INFO setupTables() (88) - Die Connection conSecurity vor dem
              createtable: weblogic.jdbc.rmi.SerialConnection@7c6daa
              INFO setupTables() (89) - Die Connection conContent vor dem
              createtable: weblogic.jdbc.rmi.SerialConnection@3b425
              ERROR setupTables() (101) - Konnte kein table init machen
              java.sql.SQLException: Does not support SQL execution with no global
              transaction
                   at
              weblogic.jdbc.oci.xa.XAConnection.beforeExecute(XAConnection.java:137)
                   at
              weblogic.jdbc.oci.xa.Statement.executeUpdate(Statement.java:112)
                   at weblogic.jdbc.jta.Statement.executeUpdate(Statement.java:185)
                   at
              weblogic.jdbc.rmi.internal.StatementImpl.executeUpdate(StatementImpl.jav
              a:42)
                   at
              weblogic.jdbc.rmi.SerialStatement.executeUpdate(SerialStatement.java:54)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.jav
              a:91)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBean
              Impl.java:130)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCBe
              anEOImpl.java:64)
                   at
              de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseCo
              mmitUnitTest.java:51)
                   at
              org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTes
              tCase.java:297)
                   at
              org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servle
              tTestCaller.java:148)
                   at
              org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCal
              ler.java:199)
                   at
              org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTes
              tRedirector.java:149)
                   at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
                   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
                   at
              weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.
              java:213)
                   at
              weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServl
              etContext.java:1265)
                   at
              weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.
              java:1631)
                   at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
                   at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              INFO rollbackTransaction() (196) - Der Transaktionsstatus vor dem
              Rollback: STATUS_NO_TRANSACTION
              INFO rollbackTransaction() (197) - Die Transaktion vor dem Rollback:
              [email protected]
              ERROR rollbackTransaction() (206) - Konnte die Transaktion nicht
              backrollen.
              java.lang.IllegalStateException: Transaction does not exist
                   at
              weblogic.transaction.internal.TransactionManagerImpl.rollback(Transactio
              nManagerImpl.java:228)
                   at
              weblogic.transaction.internal.TransactionManagerImpl.rollback(Transactio
              nManagerImpl.java:222)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBean.rollbackTransaction(TPC
              Bean.java:200)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.jav
              a:102)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBean
              Impl.java:130)
                   at
              de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCBe
              anEOImpl.java:64)
                   at
              de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseCo
              mmitUnitTest.java:51)
                   at
              org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTes
              tCase.java:297)
                   at
              org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servle
              tTestCaller.java:148)
                   at
              org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCal
              ler.java:199)
                   at
              org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTes
              tRedirector.java:149)
                   at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
                   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
                   at
              weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.
              java:213)
                   at
              weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServl
              etContext.java:1265)
                   at
              weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.
              java:1631)
                   at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
                   at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              CONCLUSION
              ==========
              I'm going nuts.
              I just don't get it.
              The transaction is the same. I don't change the Connection. I start
              the Transaction at the beginning before I do anything!
              Please guys help me out.
              Thx alot.
              Stefan "it's three o'clock in the morning, my girlfriend left me, and
              my only friend is that stupid linux pinguine" Siprell
              Software-Development
              <<<<<<<<<<<<<<<<<<<<<<<<<<<
              <sitewaerts> GmbH
              Hebelstraße 15
              D-76131 Karlsruhe
              Tel: +49 (721) 920 918 22
              Fax: +49 (721) 920 918 29
              http://www.sitewaerts.de
              >>>>>>>>>>>>>>>>>>>>>>>>>>>
              

    Hi Priscilla
              (did you ever see the movie ? :-))
              Well I moved away from the idea of using bean managed transaction. I'll
              be using Container Managed Transactions. To modify the
              transactionalbehaviour I'll write proxymethods which have certain
              different containermanaged transaction properties, but which all call
              the same private methods.
              But it works! Here is my experience:
              - I was doing a DDL statement: I was trying to create new Tables, which
              is a definite "no-go"
              - pay careful attention to:
              http://edocs.bea.com/wls/docs60/jta/trxejb.html#1051405
                        and
              http://edocs.bea.com/wls/docs60/jta/trxejb.html#1051741
              and use these Settings for the Pool, don't ask me why, but it took me
              hours to find it out by myself:
                   <JDBCConnectionPool CapacityIncrement="5"
              DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
              LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
              Properties="user=xxx; password=xxx; server=xxx.xxx.xxx"
              RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
              TestTableName="Users" SupportsLocalTransaction="true"/>
              where as the server (shown as: xxx.xxx.xxx) is the TNS Name of the
              Oracle Driver.
              It works great.
              Another thing you guys might want to do is write a simple StatelessSB
              which does JDBC calls and two different database Connections.
              Then write a UnitTest which calls this bean a couple hundred times (with
              the same transaction). Have one test do clean writes, and another which
              causes some SQL-Exception (too long Data Columns, or likewise).
              Always count the entries and see if everything worked out. We're using
              this SetupConstruction to test new combinations of AS(sorry Priscilla) /
              Database / Db-Drivers to have a "standard test".
              I know my two cents were uncalled for, but it might save you some
              time.....
              thanx for your help
              Stefan
              -----Ursprüngliche Nachricht-----
              Von: Priscilla Fung [mailto:[email protected]]
              Bereitgestellt: Donnerstag, 2. August 2001 21:42
              Bereitgestellt in: transaction
              Unterhaltung: Two phase commit and bean managed transactions
              Betreff: Re: Two phase commit and bean managed transactions
              Hi Stefan,
              Looks like you have not actually begun a transaction by calling
              UserTransaction.begin(),
              so your setupTables method is really executing with no transaction
              context.
              Priscilla
              Stefan Siprell <[email protected]> wrote:
              >To all the Transaction GURUS!
              >
              >Hi guys (-and gals).
              >I've been doing J2EE for quite a while, but today was my first at
              >XA-Transactions and Bean Managed Transactions.
              >
              >Why am I doing this?
              >====================
              >Well I have to be able to controll the transactionalbehaviour of my
              >bean
              >during runtime, since some bean calls would cause a transactional
              >overflow due to the stress they would cause to the system, whereas
              >smaller bean calls need to run in one transaction.
              >-> Therefore I need Bean Managed Transactions
              >Since the bean does a call on two Database Connections it has to use
              >a
              >XA-Transaction.
              >-> Therefore I need XA-Transactions.
              >
              >Abstract
              >========
              >- I just can't get a User TransAction into the right Status it stays
              >in 'STATUS_NO_TRANSACTION' all the time
              >- Therefore the SQL Commands can be comitted 'java.sql.SQLException:
              >Does not support SQL execution with no global transaction'
              >- Therefore I can't do a rollback 'java.lang.IllegalStateException:
              >Transaction does not exist'
              >- Therefore I wrote this mail.
              >
              >I don't want to be a smart-"ass" writing such a detailed and indepth
              >mail. I just would like to show that I tried, and would like to have
              >some replies from you guys.
              >
              >Below are my configurations, code and logfiles.
              >
              >Thanx for taking your time and hope that the other people may learn
              >something as well.
              >
              >cu
              >
              >Stefan
              >
              >
              >Scenario
              >========
              >
              >used Software
              >-------------
              >Bea Weblogic (WL) 6.0 SPx (not real sure which SP i have)
              >Oracle 8.1.6 using the API-Version 8
              >
              >
              >I configured the system as follows:
              >(ofcourse I 'xxx'ed out all of the confidential data, sorry guys;-))
              >excerpt from:
              >
              >config.xml
              >----------
              ><JDBCConnectionPool CapacityIncrement="5"
              >DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="2"
              >LoginDelaySeconds="1" MaxCapacity="5" Name="oraclePool"
              >Properties="user=xxx;password=xxx;dll=ocijdbc8;protocol=thin"
              >RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
              >TestTableName="languages" URL="jdbc:oracle:thin:@xxx:1521:xxx "/>
              >
              ><!-- Since this is our Main Datasource I would not like to use a XA
              >Transaction due to performance Issues
              >and the TxDataSource:
              >-->
              >
              ><JDBCTxDataSource EnableTwoPhaseCommit="true"
              >JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
              >PoolName="oraclePool" Targets="fbsserver"/>
              >
              ><!-- no comment required -I hope.
              >Next comes the "special" Pool
              >-->
              >
              ><JDBCConnectionPool CapacityIncrement="5"
              >DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
              >LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
              >Properties="user=xxx;password=xxx;server=xxx.xxx.xxx"
              >RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
              >TestTableName="Users" SupportsLocalTransaction="true"/>
              >
              ><!-- Well since there can only be one none XARessourceManager involved
              >in a 2PC
              >(keyword: Two Phase Commit) I will have to use a XACapable Driver for
              >the other
              >Datasource. Due to all the bugs in the oracle.xxx driver. I'll be
              >using the jdriver for oci.
              >I activated 'SupportsLocalTransaction' hoping it would solve my
              >problem - without effect. I just left in there now, since it made
              >sense me. Not?
              >Again the TxDataSource:
              >-->
              >
              ><JDBCTxDataSource EnableTwoPhaseCommit="true"
              >JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
              >Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
              >
              ><!-- The System starts right up and can locate the test tables and
              >everything. So I think all of this stuff is working here -->
              >
              >
              >
              >ejb-jar.xml
              >-----------
              ><ejb-jar>
              >     <enterprise-beans>
              >          <session>
              >               <ejb-name>TPCTestBean</ejb-name>
              >     
              ><home>de.sitewaerts.futuna.common.test.tpcbean.TPCHome</home>
              >     
              ><remote>de.sitewaerts.futuna.common.test.tpcbean.TPC</remote>
              >     
              ><ejb-class>de.sitewaerts.futuna.common.test.tpcbean.TPCBean</ejb-class>
              >               <session-type>Stateless</session-type>
              >               <transaction-type>Bean</transaction-type>
              >          </session>
              >     </enterprise-beans>
              >     <assembly-descriptor/>
              ></ejb-jar>
              >
              ><!-- Originally I had the assembly-descriptor full of transaction
              >requirements. I thought since
              >the bean is handling all of the transaction stuff itself, it might get
              >confused by the 'container-transaction'
              >properties, and deleted them. Do I need them anyway?-->
              >
              >weblogic-ejb-jar.xml
              >--------------------
              ><weblogic-ejb-jar>
              >     <weblogic-enterprise-bean>
              >          <ejb-name>TPCTestBean</ejb-name>
              >          <stateless-session-descriptor/>
              >          <jndi-name>finstral/ejb/test_tpc</jndi-name>
              >     </weblogic-enterprise-bean>
              ></weblogic-ejb-jar>
              >
              ><!-- Nothing I have to explain here -->
              >
              >BeanCode (from the implementingBeanClass:
              >'de.sitewaerts.futuna.common.test.tpcbean.TPCBean')
              >-----------------------------------------------------------------------
              >---------------------
              >
              > public void setupTables() throws RemoteException
              > {
              > UserTransaction tx = getTransaction();
              > //getTransaction calls: 'tx = sCtx.getUserTransaction()' and does
              >some errorhandling
              >
              > log.info("Die Transaktion vor den Connections: "+tx.toString());
              > //Sorry bout the German. You should get the Message though.
              > log.info("Der Transaktionsstatus vor den Connections:
              >"+transactionStatus(tx));
              >
              > Connection conSecurity = getConnection(DATASOURCE_SECURITY, tx);
              > //gets a Connection via a DataSourceName from the JNDI tree
              > Connection conContent = getConnection(DATASOURCE_CONTENT, tx);
              >
              > log.info("Die frische Connection conSecurity: "+conSecurity);
              > log.info("Die frische Connection conContent: "+conContent);
              >
              > tearDownTable(conSecurity);
              > //Does nothing special
              > tearDownTable(conContent);
              >
              > log.info("Die Transaktion nach dem Teardown: "+tx.toString());
              > log.info("Der Transaktionsstatus nach dem Teardown:
              >"+transactionStatus(tx));
              >
              > Statement stmt = null;
              > try
              > {
              > stmt = conSecurity.createStatement();
              > //Well its getting interesting now.....
              >
              > log.info("Die Transaktion vor dem createtable: "+tx.toString());
              > log.info("Der Transaktionsstatus vor dem createtable:
              >"+transactionStatus(tx));
              > log.info("Die Connection conSecurity vor dem createtable:
              >"+conSecurity);
              > log.info("Die Connection conContent vor dem createtable:
              >"+conContent);
              >
              > stmt.executeUpdate(CREATE_TABLE);
              > //above is the row 91 -> throws: 'java.sql.SQLException: Does
              >not support SQL execution with no global transaction'
              >
              > stmt.close();
              >
              > stmt = conContent.createStatement();
              > stmt.executeUpdate(CREATE_TABLE);
              > stmt.close();
              > commitTransaction(tx);
              > }
              > catch (SQLException sqle)
              > {
              > log.error("Konnte kein table init machen", sqle);
              > rollbackTransaction(tx);
              > //The Code for this method is below
              > throw new EJBException(sqle);
              > }
              > finally
              > {
              > closeConnection(conSecurity);
              > closeConnection(conContent);
              > }
              > }
              >
              > protected void rollbackTransaction(UserTransaction tx)
              > {
              > log.info("Der Transaktionsstatus vor dem Rollback:
              >"+transactionStatus(tx));
              > log.info("Die Transaktion vor dem Rollback: "+tx.toString());
              > try
              > {
              > tx.rollback();
              > //above is row 200 -> throws: 'java.lang.IllegalStateException:
              >Transaction does not exist'
              > log.info("Der Transaktionsstatus nach dem Rollback:
              >"+transactionStatus(tx));
              > log.info("Die Transaktion nach dem Rollback: "+tx.toString());
              > }
              > catch (Exception e)
              > {
              > log.error("Konnte die Transaktion nicht backrollen.", e);
              > throw new EJBException(e);
              > }
              > }
              >
              >Log Excerpt
              >===========
              >INFO setupTables() (66) - Die Transaktion vor den Connections:
              >[email protected]
              >INFO setupTables() (67) - Der Transaktionsstatus vor den Connections:
              >STATUS_NO_TRANSACTION
              >INFO setupTables() (72) - Die frische Connection conSecurity:
              >weblogic.jdbc.rmi.SerialConnection@7c6daa
              >INFO setupTables() (73) - Die frische Connection conContent:
              >weblogic.jdbc.rmi.SerialConnection@3b425
              >INFO setupTables() (78) - Die Transaktion nach dem Teardown:
              >[email protected]
              >INFO setupTables() (79) - Der Transaktionsstatus nach dem Teardown:
              >STATUS_NO_TRANSACTION
              >INFO setupTables() (86) - Die Transaktion vor dem createtable:
              >[email protected]
              >INFO setupTables() (87) - Der Transaktionsstatus vor dem createtable:
              >STATUS_NO_TRANSACTION
              >INFO setupTables() (88) - Die Connection conSecurity vor dem
              >createtable: weblogic.jdbc.rmi.SerialConnection@7c6daa
              >INFO setupTables() (89) - Die Connection conContent vor dem
              >createtable: weblogic.jdbc.rmi.SerialConnection@3b425
              >ERROR setupTables() (101) - Konnte kein table init machen
              >java.sql.SQLException: Does not support SQL execution with no global
              >transaction
              >     at
              >weblogic.jdbc.oci.xa.XAConnection.beforeExecute(XAConnection.java:137)
              >     at
              >weblogic.jdbc.oci.xa.Statement.executeUpdate(Statement.java:112)
              >     at weblogic.jdbc.jta.Statement.executeUpdate(Statement.java:185)
              >     at
              >weblogic.jdbc.rmi.internal.StatementImpl.executeUpdate(StatementImpl.ja
              v
              >a:42)
              >     at
              >weblogic.jdbc.rmi.SerialStatement.executeUpdate(SerialStatement.java:54
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.ja
              v
              >a:91)
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBea
              n
              >Impl.java:130)
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCB
              e
              >anEOImpl.java:64)
              >     at
              >de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseC
              o
              >mmitUnitTest.java:51)
              >     at
              >org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTe
              s
              >tCase.java:297)
              >     at
              >org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servl
              e
              >tTestCaller.java:148)
              >     at
              >org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCa
              l
              >ler.java:199)
              >     at
              >org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTe
              s
              >tRedirector.java:149)
              >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
              >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
              >     at
              >weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl
              >java:213)
              >     at
              >weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServ
              l
              >etContext.java:1265)
              >     at
              >weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl
              >java:1631)
              >     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
              >     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              >INFO rollbackTransaction() (196) - Der Transaktionsstatus vor dem
              >Rollback: STATUS_NO_TRANSACTION
              >INFO rollbackTransaction() (197) - Die Transaktion vor dem Rollback:
              >[email protected]
              >ERROR rollbackTransaction() (206) - Konnte die Transaktion nicht
              >backrollen.
              >java.lang.IllegalStateException: Transaction does not exist
              >     at
              >weblogic.transaction.internal.TransactionManagerImpl.rollback(Transacti
              o
              >nManagerImpl.java:228)
              >     at
              >weblogic.transaction.internal.TransactionManagerImpl.rollback(Transacti
              o
              >nManagerImpl.java:222)
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.rollbackTransaction(TP
              C
              >Bean.java:200)
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.ja
              v
              >a:102)
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBea
              n
              >Impl.java:130)
              >     at
              >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCB
              e
              >anEOImpl.java:64)
              >     at
              >de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseC
              o
              >mmitUnitTest.java:51)
              >     at
              >org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTe
              s
              >tCase.java:297)
              >     at
              >org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servl
              e
              >tTestCaller.java:148)
              >     at
              >org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCa
              l
              >ler.java:199)
              >     at
              >org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTe
              s
              >tRedirector.java:149)
              >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
              >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
              >     at
              >weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl
              >java:213)
              >     at
              >weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServ
              l
              >etContext.java:1265)
              >     at
              >weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl
              >java:1631)
              >     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
              >     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              >
              >
              >CONCLUSION
              >==========
              >I'm going nuts.
              >I just don't get it.
              >The transaction is the same. I don't change the Connection. I start
              >the Transaction at the beginning before I do anything!
              >Please guys help me out.
              >Thx alot.
              >
              >Stefan "it's three o'clock in the morning, my girlfriend left me, and
              >my only friend is that stupid linux pinguine" Siprell
              >Software-Development
              ><<<<<<<<<<<<<<<<<<<<<<<<<<<
              ><sitewaerts> GmbH
              >Hebelstraße 15
              >D-76131 Karlsruhe
              >
              >Tel: +49 (721) 920 918 22
              >Fax: +49 (721) 920 918 29
              >http://www.sitewaerts.de
              >>>>>>>>>>>>>>>>>>>>>>>>>>>>
              >
              >
              >
              

  • ORA-14552: cannot perform a DDL, commit or rollback inside a query or DML;;

    Hi all,
    I have a problem!
    I have one PL SQL function doing an Update and insert into some oracle tables, this function return one number (0 or 1 or 2).
    I'm excuting this query from one PHP program to call the function :
    SELECT SALE.DB_FUNC_ASSOCIATE_TB2U('[email protected]',123)
    FROM dual;
    the problem that I have these errors :
    ERROR DB_FUNC_ASSOCIATE_TB2U Level 1 : ORA-01403: no data found
    ERROR DB_FUNC_ASSOCIATE_TB2U : ORA-14552: cannot perform a DDL, commit or rollback inside a query or DML
    there's a mean that i can do to call this function from PHP without getting this Error such as I tested this function using the script below and it works fine:
    declare
    a number;
    begin
    a:= SALE.DB_FUNC_ASSOCIATE_TB2U('[email protected]',123) ;
    end;
    Please help me :)
    regards,

    Sure, it works in the sense that you would no longer get an error.
    Creating this as an autonomous transaction, however, is going to blow your transactional integrity. You've now got code that is being called as the result of a SELECT operation (something that everyone that comes after you will assume is read-only) that commits outside of the current transaction scope. That is almost always a bad thing.
    In addition, having a WHEN OTHERS without a RAISE is almost always a bug. You're completely hiding the error message plus you're discarding proper exception handling in order to provide a return code and assuming that the caller is going to check the status. Relying on return status codes is normally a bad idea because it's very easy on the client side to forget to check the return code. Even if the client were to check the return code, it has no idea what went wrong, so it can't even log the root cause of the error.
    Justin

  • How to measure undo at a session level

    Below is what are trying to do.
    We are trying to implement Oracle's table block compression feature.
    In doing so, in one of our testing we discovered that the session performing the DML (inserts) generated almost 30x undo.
    We measured this undo by using below query (before the transaction commited).
    SELECT a.sid, a.username, used_ublk, used_ublk*8192 bytes
    FROM v$session a, v$transaction b
    WHERE a.saddr = b.ses_addr
    However, above is at a transaction level since it still not committed, we would lose this value once the transaction either committed or rolled back, for this reason, we are trying to find an equivalent statistic at a session level.
    1. What we are trying to find it out whether if an equivalent session level statistic exist to measure the amount of undo generated?
    2. Is the undo generated always in terms of "undo blocks?"
    3. When querying v$statname for name like '%undo%' we came across several statistics, the closest one
    undo change vector size -in bytes?
    4. desc test_table;
    Name Type
    ID NUMBER
    sql> insert into test_table values (1);
    5. However when we run the query against:
    SELECT s.username,sn.name, ss.value
    FROM v$sesstat ss, v$session s, v$statname sn
    WHERE ss.sid = s.sid
    AND sn.statistic# = ss.statistic#
    AND s.sid =204
    AND sn.name ='undo change vector size'
    SID USERNAME NAME BYTES
    204 NP4 undo change vector size 492
    6. Query against: v$transaction
    SELECT a.sid, a.username, used_ublk, used_ublk*8192 bytes
    FROM v$session a, v$transaction b
    WHERE a.saddr = b.ses_addr
    SID USED_UBLK BYTES
    204 1 8192
    What are trying to understand is:
    1. How can we or what is the correct statistic to determine how many undo blocks were generated by particular session?
    2. What is the statistic: undo change vector size? What does it really mean? or measure?

    Any transaction that generates Undo will use Undo Blocks in multiples of 1 --- i.e. the minimum allocation on disk is 8KB.
    Furthermore, an Undo_Rec does not translate to a Table Row. The Undo has to capture changes to Indexes, block splits, other actions. Multiple changes to the same table/index block may be collapsed into one undo record/block etc etc.
    Therefore, a transaction that generated 492 bytes of Undo would use 8KB of undo space because that is the minimum allocation.
    You need to test with larger transactions.
    SQL> update P_10 set col_2='ABC2' where mod(col_1,10)=0;
    250000 rows updated.
    SQL>
    SQL> @active_transactions
           SID    SERIAL# SPID         USERNAME     PROGRAM                       XIDUSN  USED_UBLK  USED_UREC
           143        542 17159        HEMANT       sqlplus@DG844 (TNS V1-V3)          6       5176     500000
    Statistic : db block changes                                      1,009,903
    Statistic : db block gets                                         1,469,623
    Statistic : redo entries                                            502,507
    Statistic : redo size                                           117,922,016
    Statistic : undo change vector size                              41,000,368
    Statistic : table scan blocks gotten                                 51,954
    Statistic : table scan rows gotten                               10,075,245Hemant K Chitale

  • Setting Session level parameter in FORMS 10g

    Hi folks,
    I want to setup session level setting for NLS DATE FORMAT in FORMS 10g at environment settings. because, i can't change these setting at database level. b,cz different client applications (i.e. .NET,Forms 10g and SQL PLUS) using different settings.
    So, i want to set this NLS DATE FORMAT for SESSION level in FORMS 10g.
    can i include this in default.env, if yes, how to include that one in .env file
    Edited by: user12212962 on Jul 23, 2010 7:18 PM

    No, i want to setup the session parameter for DATE FORMAT. why because, i'm executing oracle stored procedure from forms and this procedure does some logic based on date value.
    In this procedure, i have used all variables as DATE datatype only. and i can't change this procedure due to some other client application's using same procedure like JAVA, .NET, Oracle BI and scheduled jobs. And all these application's working fine, even when i use forms 6i also it's working.
    but when we use FORMS10g, date was treating as DD-MON-RR and all other client applications using DD-MON-YYYY due to session level setting and at database level also has a same format i.e. DD-MON-YYYY. because i logged this NLS value in audit_table when i executed through FORMS10G, JAVA application,.NET
    May be some where it's changing this setting to DD-MON-RR for FORMS10g. Is any settings at Oracle APP server level
    (iAS) for this parameter?

  • Fundamental questions on redo logs and rollbacks

    Hi all,
    Some basic questions, I really want to understand it very clearly.
    Suppose that we have updated few records in a table. We know that the blocks to be updated will be fetched into buffer cache, they will be updated with new value and commited eventually. The questions I have are ,
    1) What exact information will go to redo log ? is it a copy of the block before change and copy of the block after change ?
    2) What exactly goes to rollback segment? is it copy of block before change (for update) and just the rowid for inserted row and the copy of block for a deleted row ?
    3) Whatever we do, is it the whole block that goes to redo or rollback ? Means if there are 10 rows in the block and we update one of them, still whole block goes to redo or rollback ?
    4) If we rollback, what goes where ? Is there anything that goes to redo if we rollback ?
    Please explain.
    Thanks.

    Redo stores changes made in the database, and undo/rollback stores the reverse of those changes. Data blocks may be changed prior to a commit, and recorded in both locations.
    So, when a database is recovered, redo is applied to the backup datafiles, rolling every change forward, and then undo is applied to reverse any uncomitted transactions.
    Undo/rollback can also be used simply to roll back a transaction in an active instance. Redo is only used during instance recovery.
    I don't know if this is tracked via the storage of block images, or if it just stores the change itself.
    -cf

  • Cannot commit or rollback  a JDBC Connection from CAF project

    Hi Everybody,
    I'm working in CE 7.10. I have a CAF Project that gets a JDBC connection from a Custom Datasource to an external Database.
    Here is the code:
      try
        Context ctx = new InitialContext();
        DataSource ds = (DataSource) ctx.lookup("jdbc/MYDATABASE");               
        con = ds.getConnection();
        con.setAutoCommit(false);
        Statement statement = con.createStatement();
        String updateStatement = "UPDATE TABLE...";
        statement.executeUpdate(updateStatement);
        con.commit();
        catch(SQLException sqle){
             con.rollback();
    I got the following exception on line "con.setAutoCommit(false);":  --> "Cannot begin JDBC transaction from this connection of "MYDATABASE" DataSource. JTA transaction has already started."
    and the following on line "con.commit() / con.rollback()" : --> "Cannot commit JDBC transaction from this connection of "MYDATABASE" DataSource. This resource participates in a JTA transaction."
    If I run the same code from a webDynpro or a J2EE project it works ok, but not from a CAF Application Service. I tried to do it in a simple Class in the CAF Project and call this clas from the Application service, but I get the same error.
    Any Ideas??
    Thanks a lot!
    Regards.

    Solved with   "SessionContext.setRollbackOnly()" instruccion.
    Regards.

Maybe you are looking for