C.15.2 The ADVISE_NOTHING procedure

The ADVISE_NOTHING procedure specifies that no in-doubt transaction advice is sent to remote databases during distributed transactions. Advice is handled as described for ADVISE_COMMIT. This procedure is equivalent to the SQL command, ALTER SESSION ADVISE NOTHING. The specification is:

PROCEDURE DBMS_TRANSACTION.ADVISE_NOTHING;

C.15.3 The ADVISE_ROLLBACK procedure

The ADVISE_ROLLBACK procedure specifies that "rollback" in-doubt transaction advice is sent to remote databases during distributed transactions. Advice is handled as described for ADVISE_COMMIT. This procedure is equivalent to the SQL command, ALTER SESSION ADVISE ROLLBACK. The specification is:

PROCEDURE DBMS_TRANSACTION.ADVISE_ROLLBACK;

C.15.4 The COMMIT procedure

The COMMIT procedure ends the current transaction and makes permanent all pending changes. It also erases savepoints and releases all locks. It is provided primarily for completeness. It is equivalent to the COMMIT command, which is already implemented as part of PL/SQL. I recommend using the SQL command rather than the procedure. The specification is:

PROCEDURE DBMS_TRANSACTION.COMMIT;

C.15.5 The COMMIT_COMMENT procedure

The COMMIT_COMMENT procedure performs a commit and sends a "commit" in-doubt transaction comment to remote databases during distributed transactions. This comment appears on the remote database in the TRAN_COMMENT column of the DBA_2PC_PENDING data dictionary view if the distributed transaction becomes in-doubt (i.e., a network or machine failure occurs during the commit). The remote database administrator can then review the DBA_2PC_PENDING information and manually commit or roll back in-doubt transactions using the FORCE clause of the COMMIT or ROLLBACK commands. This procedure is equivalent to the SQL command, COMMIT COMMENT. The specification is:

PROCEDURE DBMS_TRANSACTION.COMMIT_COMMENT (cmnt VARCHAR2);

C.15.6 The COMMIT_FORCE procedure

The COMMIT_FORCE procedure manually commits local in-doubt, distributed transactions. Any decisions to force in-doubt transactions should be made after consulting with the database administrator(s) at the remote database location(s). If the decision is made to locally force any transactions, the database administrator should either commit or rollback such transactions as was done by nodes that successfully resolved the transactions. Otherwise, the administrator should query the DBA_2PC_PENDING views ADVICE and TRAN_COMMENT columns for further insight.[2] This procedure is equivalent to the SQL command, COMMIT FORCE. The specification is:

[2] For more information on this topic, see "Manually Overriding In-Doubt Transactions" in Oracle8 Server Distributed Systems .

PROCEDURE DBMS_TRANSACTION.COMMIT_FORCE (xid VARCHAR2, scn VARCHAR2 DEFAULT NULL);

C.15.7 The READ_ONLY procedure

The READ_ONLY procedure establishes the current transaction as a read-consistent transaction (i.e., repeatable reads). Once a transaction is designated as read-only, all queries within that transaction can only see changes committed prior to that transactions start. Thus, read-only transactions let you issue two or more queries against tables that may be undergoing concurrent inserts or updates, and yet return results consistent as of the transaction's start. This procedure is equivalent to the SQL command, SET TRANSACTION READ ONLY. The specification is:

PROCEDURE DBMS_TRANSACTION.READ_ONLY;

C.15.8 The READ_WRITE procedure

The READ_WRITE procedure establishes the current transaction as a read-write transaction. This is the default transaction mode. This procedure is equivalent to the SQL command, SET TRANSACTION READ WRITE. The specification is:

PROCEDURE DBMS_TRANSACTION.READ-WRITE;

C.15.9 The ROLLBACK procedure

The ROLLBACK procedure ends the current transaction and undoes all pending changes. It also erases savepoints and releases all locks. It is provided primarily for completeness. It is equivalent to the ROLLBACK command, which is already implemented as part of PL/SQL. I recommend using the SQL command rather than the procedure. The specification is:

PROCEDURE DBMS_TRANSACTION.ROLLBACK;

C.15.10 The ROLLBACK_FORCE procedure

The ROLLBACK_FORCE procedure manually rolls back local in-doubt, distributed transactions. The parameter identifies the transaction's local or global transaction ID. To find these transaction IDs, query the data dictionary view DBA_2PC_PENDING. Any decisions to force in-doubt transactions should be made after consulting with the database administrator(s) at the remote database location(s), as described for COMMIT_FORCE. This procedure is equivalent to the SQL command, ROLLBACK FORCE. The specification is:

PROCEDURE DBMS_TRANSACTION.ROLLBACK_FORCE (xid VARCHAR2);

C.15.11 The ROLLBACK_SAVEPOINT procedure

The ROLLBACK_SAVEPOINT procedure rolls back the current transaction to a previously declared savepoint. It is provided primarily for completeness. It is equivalent to the ROLLBACK SAVEPOINT command, which is already implemented as part of PL/SQL. I recommend using the SQL command rather than the procedure. The specification is:

PROCEDURE DBMS_TRANSACTION.ROLLBACK_SAVEPOINT;

C.15.12 The SAVEPOINT procedure

The SAVEPOINT procedure identifies a logical point within a transaction to which you can later roll back. It is provided primarily for completeness. It is equivalent to the SAVEPOINT command, which is already implemented as part of PL/SQL. I recommend using the SQL command rather than the procedure. The specification is:

PROCEDURE DBMS_TRANSACTION.SAVEPOINT;

C.15.13 The USE_ROLLBACK_SEGMENT procedure

The USE_ROLLBACK_SEGMENT procedure assigns the current transaction to the specified rollback segment. This option also establishes the transaction as a read-write transaction. The rollback segment specified must be online. You cannot use both the READ_ONLY and USE_ROLLBACK_SEGMENT procedures within the same transaction. Read-only transactions do not generate rollback information and thus cannot be assigned rollback segments. This procedure is equivalent to the SQL command, SET TRANSACTION USE ROLLBACK SEGMENT. The specification is:

PROCEDURE DBMS_TRANSACTION.USE_ROLLBACK_SEGMENT (rb_name VARCHAR2);

C.15.14 The BEGIN_DISCRETE_TRANSACTION procedure

The BEGIN_DISCRETE_TRANSACTION procedure streamlines transaction processing so short transactions can execute more rapidly . During discrete transactions, normal redo information is generated although it is stored in a separate location in memory. When the discrete transaction commits, the redo information is written to the redo log file and data block changes are applied directly. As such, there is no need for undo information in rollback segments. The block is then written to the database file in the usual manner. The call to this procedure is effective only until the transaction is committed or rolled back; the next transaction is processed as a standard transaction. Any PL/SQL using this procedure must be coded to ensure that the transaction is attempted again in the event of a discrete transaction failure.[3] The specification is:

[3] For more information on this topic, see "Using Discrete Transactions" in Oracle8 Server Tuning .

PROCEDURE DBMS_TRANSACTION.BEGIN_DISCRETE_TRANSACTION;

C.15.15 The PURGE_MIXED procedure

The PURGE_MIXED procedure deletes information about a given in-doubt, distributed transaction that has had mixed outcomes due to a transaction resolution mismatch. This occurs when an in-doubt, distributed transaction is forced to commit or roll back on one node and other nodes do the opposite . Oracle cannot automatically resolve such inconsistencies, but it does flag entries in the DBA_2PC_PENDING view by setting the MIXED column to yes. When the database administrator is sure that any inconsistencies for a transaction have been resolved, he or she can call the PURGE_MIXED procedure.[4] The specification is:

[4] For more information on this topic, see "Manually Overriding In-Doubt Transactions" in Oracle8 Server Distributed Systems .

PROCEDURE DBMS_TRANSACTION.PURGE_MIXED (xid VARCHAR2);

C.15.16 The PURGE_LOST_DB procedure

The PURGE_LOST_DB procedure deletes information about a given in-doubt, distributed transaction that has had mixed outcomes due to a lost database. This occurs when an in-doubt, distributed transaction is able to commit or roll back on one node and other nodes have either destroyed or recreated their databases. Oracle cannot automatically resolve such inconsistencies, as described in PURGE_MIXED. The specification is:

PROCEDURE DBMS_TRANSACTION.PURGE_LOST_DB (xid VARCHAR2);

C.15.17 The LOCAL_TRANSACTION_ID function

The LOCAL_TRANSACTION_ID function returns the unique identifier for the current transaction. The function returns NULL if there is no current transaction. The specification is:

FUNCTION DBMS_TRANSACTION.LOCAL_TRANSACTION_ID (create_transaction BOOLEAN := false) RETURN VARCHAR2;

C.15.18 The STEP_ID function

The STEP_ID function returns the unique positive integer that orders the DML operations of the current transaction. The specification is:

FUNCTION DBMS_TRANSACTION.STEP_ID RETURN VARCHAR2;

---

C.14 DBMS_SQL		C.16 DBMS_UTILITY

---

Copyright (c) 2000 O'Reilly & Associates. All rights reserved.