Transaction Handling

Configuring Two-Phase Commit Engine

If you have more than a single database involved in your transaction, you must designate a two-phase commit engine for managing all changes to all databases involved in the transaction. A two-phase commit engine is responsible for contacting all of the databases at the end of the transaction and managing the commit or rollback of all updates to all included databases. Thus, this two-phase commit engine must have access to database links to each database included within the transaction.

To configure for a two-phase commit, your system administrator must do the following:

Designate an Oracle8i database as the two-phase commit engine.
Configure database links from the two-phase commit engine to each database that may be involved in the global transaction. This is necessary for the two-phase commit engine to communicate with each database at the end of the transaction.
Provide the database link name in the -dblink option of bindds for each individual database when binding that database's DataSource into the namespace.
```
bindds /test/empDatabase -url jdbc:oracle:thin:@empHost:5521:ORCL 

	-dstype jta -dblink 2pcToEmp.oracle.com
```

Provide the two-phase commit engine's fully-qualified database address, username, and password when binding the UserTransaction into the namespace.

bindut /test/myUT -url sess_iiop://dbsun.mycompany.com:2481:ORCL 

	-user SCOTT -password TIGER

Note:
Verify that the user bound with the UserTransaction has FORCE ANY TRANSACTION granted to the user that bound this object. This privilege enables the user to commit this transaction. In this example, you would execute the following:
GRANT FORCE ANY TRANSACTION TO SCOTT

Once all of this configuration is complete, your application differs from the single-phase commit scenario in the following aspects:

If you are demarcating your transaction from the client, you can chose to not supply the username and password in the UserTransaction binding; but instead, provide the username/password when retrieving the UserTransaction object within the Hashtable in the InitialContext used when looking up the UserTransaction.

The following example shows a server object that performs an in-session activation to retrieve both the UserTransaction and DataSource objects that have been bound locally. The UserTransaction was bound with the two-phase commit engine's URL, username, and password. The DataSource objects were all bound with the proper database links.

//with the environment set, create the initial context.
InitialContext ic = new InitialContext ();
UserTransaction ut = (UserTransaction)ic.lookup ("/test/myUT");

//With the same username and password for the 2pc engine,
// lookup the local datasource and a remote database.
DataSource localDS = (DataSource)ic.lookup ("/test/localDS");

//remote lookup requires environment setup
Hashtable env = new Hashtable ();
env.put (Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
env.put (Context.SECURITY_PRINCIPAL, user);
env.put (Context.SECURITY_CREDENTIALS, password);
env.put (Context.SECURITY_AUTHENTICATION, ServiceCtx.NON_SSL_LOGIN);
env.put(jdbc_accessURLContextFactory.CONNECTION_URL_PROP, namespaceURL);
Context ic = new InitialContext (env);
 
//Register a JDBC OracleDriver. 
DriverManager.registerDriver (new oracle.jdbc.driver.OracleDriver());
//retrieve the DataSource for the remote database
DataSource remoteDS = (DataSource)ic.lookup ("jdbc_access://test/NewYorkDS");

//retrieve connections to both local and remote databases
Connection localConn = localDS.getConnection ();
Connection remoteConn = remoteDS.getConnection ();
...
//close the connections
localConn.close();
remoteConn.close();

//end the transaction
 ut.commit();