Committing Transactions
Committing a transaction means making permanent the changes performed by the SQL statements within the transaction.

Before a transaction that modifies data is committed, the following has occurred:

Oracle has generated rollback segment records in rollback segment buffers of the system global area (SGA). The rollback information contains the old data values changed by the SQL statements of the transaction.

Oracle has generated redo log entries in the redo log buffer of the SGA. The redo log record contains the change to the data block and the change to the rollback block. These changes may go to disk before a transaction is committed.

The changes have been made to the database buffers of the SGA. These changes may go to disk before a transaction actually is committed.

***Note: ****
The data changes for a committed transaction, stored in the database buffers of the SGA, are not necessarily written immediately to the datafiles by the database writer (DBWn) background process. This writing takes place when it is most efficient for the database to do so. It may happen before the transaction commits or, alternatively, it may happen some time after the transaction commits.

--------------------------------------------------------------------------------


/* AND ALSO TO YOUR PREVIOUS Q ABOUT THE TRANSACTION DEFFERING,ALTHOUGH IT IS CNSTR DEFERRING.......... */



Discrete Transaction Management
Application developers can improve the performance of short, nondistributed transactions by using the BEGIN_DISCRETE_TRANSACTION procedure. This procedure streamlines transaction processing so that short transactions can execute more rapidly.

During a discrete transaction, all changes made to any data are deferred until the transaction commits. Of course, other concurrent transactions are unable to see the uncommitted changes of a transaction whether the transaction is discrete or not.

The following events occur during a discrete transaction:

Oracle generates redo information, but stores it in a separate location in memory.

When the transaction issues a commit request, Oracle writes the redo information to the redo log file along with other group commits.

Oracle applies the changes to the database block directly to the block.

Oracle returns control to the application after the commit completes.

This transaction design eliminates the need to generate undo information, since the block is not modified until the transaction is committed, and the redo information is stored in the redo log buffers.

There is no interaction between discrete transactions, which always generate redo, and the NOLOGGING mode, which applies only to direct path operations. Discrete transactions may therefore be issued against tables that have the NOLOGGING attribute set.


COURTESY......
http://otn.oracle.com/docs/products/...5trans.htm#222

IT IS INETERESTING!