There is no Oracle SQL statement to explicitly start a new transaction. Oracle server implicitly starts a new transaction with the following two conditions:
* The first executable statement of a new user session will automatically start a new transaction.
* The first executable statement after a previous transaction has been ended will automatically start a new transaction.
There are several ways a current Oracle transaction can be ended:
* Running the COMMIT statement will explicitly end the current transaction.
* Running the ROLLBACK statement will explicitly end the current transaction.
* Running any DDL statement will implicitly end the current transaction.
* Disconnecting a user session will implicitly end the current transaction.
* Killing a user session will implicitly end the current transaction.
samedi 27 octobre 2007
XAResource interface
This interface is a Java mapping of the industry standard X/Open XA protocol that allows a resource manager to participate in a transaction. The component of the driver connected with the XAResource interface is responsible for "translating" between the transaction manager and the resource manager.
JTA Interfaces
Developers of transaction manager code must be conversant with all three interfaces of JTA: UserTransaction, TransactionManager, and XAResource, which are described in the Sun Java Transaction API (JTA) specification. The JDBC API Tutorial and Reference, Third Edition is also a useful reference.
Two-Phase Commit Protocol
The transaction manager controls the boundaries of the transaction and is responsible for the final decision as to whether or not the total transaction should commit or rollback. This decision is made in two phases, called the Two-Phase Commit Protocol.
In the first phase, the transaction manager polls all of the resource managers (RDBMSs) involved in the distributed transaction to see if each one is ready to commit. If a resource manager cannot commit, it responds negatively and rolls back its particular part of the transaction so that data is not altered.
In the second phase, the transaction manager determines if any of the resource managers have responded negatively, and, if so, rolls back the whole transaction. If there are no negative responses, the translation manager commits the whole transaction, and returns the results to the application.
In the first phase, the transaction manager polls all of the resource managers (RDBMSs) involved in the distributed transaction to see if each one is ready to commit. If a resource manager cannot commit, it responds negatively and rolls back its particular part of the transaction so that data is not altered.
In the second phase, the transaction manager determines if any of the resource managers have responded negatively, and, if so, rolls back the whole transaction. If there are no negative responses, the translation manager commits the whole transaction, and returns the results to the application.
Transaction Branch
Although the final commit/rollback decision treats the transaction as a single logical unit, there can be many transaction branches involved. A transaction branch is associated with a request to each resource manager involved in the distributed transaction.
Requests to three different RDBMSs, therefore, require three transaction branches. Each transaction branch must be committed or rolled back by the local resource manager.
Requests to three different RDBMSs, therefore, require three transaction branches. Each transaction branch must be committed or rolled back by the local resource manager.
XA Specification
Industry standard XA interface based on the X/Open CAE Specification Distributed Transaction Processing: The XA Specification.
Transaction Manager
A distributed transaction is a transaction that accesses and updates data on two or more networked resources. These resources could consist of several different RDBMSs housed on a single sever, for example, Oracle, SQL Server, and Sybase; or they could include several instances of a single type of database residing on a number of different servers. In any case, a distributed transaction involves coordination among the various resource managers. This coordination is the function of the transaction manager.
The transaction manager is responsible for making the final decision either to commit or rollback any distributed transaction. A commit decision should lead to a successful transaction; rollback leaves the data in the database unaltered. JTA specifies standard Java interfaces between the transaction manager and the other components in a distributed transaction: the application, the application server, and the resource managers.
Most enterprises use transaction managers and application servers because they manage distributed transactions much more efficiently than an application can.
The transaction manager is responsible for making the final decision either to commit or rollback any distributed transaction. A commit decision should lead to a successful transaction; rollback leaves the data in the database unaltered. JTA specifies standard Java interfaces between the transaction manager and the other components in a distributed transaction: the application, the application server, and the resource managers.
Most enterprises use transaction managers and application servers because they manage distributed transactions much more efficiently than an application can.
Inscription à :
Articles (Atom)