Transaction Control

When the XA library is used, transactions are not controlled by the SQL statements which commit or roll back transactions. Rather, they are controlled by an API accepted by the TM which starts and stops transactions. Most of the TMs use the TX interface for this. It includes the following functions:

tx_open	logs into the resource manager(s)
tx_close	logs out of the resource manager(s)
tx_begin	starts a new transaction
tx_commit	commits a transaction
tx_rollback	rolls back the transaction

Most TPM applications are written using a client-server architecture where an application client requests services and an application server provides services. The examples that follow use such a client-server model. A service is a logical unit of work, which in the case of the Oracle Server as the resource manager, comprises a set of SQL statements that perform a related unit of work.

For example, when a service named "credit" receives an account number and the amount to be credited, it will execute SQL statements to update information in certain tables in the database. In addition, a service might request other services. For example, a "transfer fund" service might request services from a "credit" and "debit" service.

Usually application clients request services from the application servers to perform tasks within a transaction. However, for some TPM systems, the application client itself can offer its own local services.

You can encode transaction control statements within either the client or the server; as shown in the examples.

To have more than one process participating in the same transaction, the TPM provides a communication API that allows transaction information to flow between the participating processes. Examples of communications APIs include RPC, pseudo-RPC functions, and send/receive functions.

Because the leading vendors support different communication functions, the examples that follow use the communication pseudo-function tpm_service to generalize the communications API.

X/Open has included several alternative methods for providing communication functions in their preliminary specification. At least one of these alternatives is supported by each of the leading TPM vendors.

Examples of Precompiler Applications

The first example shows a transaction started by an application server, and the second example shows a transaction started by an application client.

Example 1: Transaction started by an application server.

Client:

tpm_service("ServiceName");	     /* Request Service*/

Server:

ServiceName()

{

<get service specific data>

tx_begin();		 /* Begin transaction boundary */

EXEC SQL UPDATE ....;

/*This application server temporarily becomes a client and requests *other service.*/

tpm_service("AnotherService");

tx_commit();		/* Commit the transaction */

<return service status back to the client>

}

Example 2 Transaction started by an application client.

Client:

tx_begin();		    /* Begin transaction boundary */

tpm_service("Service1");

tpm_service("Service2");

tx_commit();		/* Commit the transaction */

Server:

Service1()

{

<get service specific data>

EXEC SQL UPDATE ....;

<return service status back to the client>

}

Service2()

{

<get service specific data>

EXEC SQL UPDATE ....;

...

<return service status back to client>

}