Table of Contents
This chapter describes transaction processing and defines transaction process management.
A transaction is a unit of work that transforms the state of a resource from one valid state to another valid state.
Tmax supports local and global transactions.
-
Local Transaction
A Local Transaction is when a single resource manager (database) participates.
-
Global Transaction
A Global Transaction is when multiple resource managers (databases) and physical entities participate in processing one logical unit. Tmax regards all transactions as global transactions. Currently, the Tmax system does not support nested transactions.
Tmax transaction processing preserves ACID (Atomicity, Consistency, Isolation, and Durability) properties when executing tasks. Transactions comply with the TX standard of the X/Open DTP model.
The following are the features of ACID.
-
Each transaction is "all or nothing". If one part of the transaction fails, the entire transaction fails and the no data is committed.
-
A completed transaction changes the database from one valid state to another valid state.
-
Transactions executed concurrently have the same result as transactions executed serially.
-
Once a transaction result is returned and committed, it maintains the same state even if a system or media failure occurs.
Global transactions that involve two or more databases use 2PC (Two-Phase Commit) to guarantee ACID properties of the transaction. The following describes the two phases of 2PC.
Data integrity is guaranteed when processing transactions with 2PC (two phase commit), and multiple function (tx_begin, tx_commit, tx_rollback, etc.) are supported to enable global transactions. In addition, a multi-thread transaction manager ensures improved resource efficiency and dynamic error logging. Dynamic error logging enables a quick response to errors and supports reliability through Recovery/Rollback. All transactions are monitored through a single interface to facilitate easy scheduling and management of transactions.
Processing Mechanism
The Tmax distributed transaction processing mechanism complies with the TX standards of the X/Open DTP model, an international standard for distributed transaction processing.
The following is the of X/Open DTP structure.
The following describes X/Open DTP components.
X/OPEN ATMI processes transactions that occur between heterogeneous DBMSs that comply with X/OPEN DTP by grouping them. The following is how distributed transactions are processed.
A transaction starts when tx_begin() is called and ends when tx_commit() or tx_rollback() is called.
tx_begin() is called to start a transaction; the process that calls tx_begin() becomes a transaction initiator. The transaction initiator also ends the transaction by calling tx_commit() or tx_rollback(). The transaction participants can affect the results of the transaction through the return values of tpreturn(). If tx_begin() attempts to starts another transaction while a transaction is being processed, the attempt fails and tperrno is set to TPEPROTO. However, the original transaction continues to be processed.
A client participating in a transaction can exclude a server from the transaction by setting flags to TPNOTRAN when calling tpcall() or tpacall(). In other words, an excluded server cannot influence the result of the transaction currently being processed.
There are two ways to declare a transaction: explicitly, when developers write transaction functions (e.g., tx_begin and tx_commit, etc.) and implicitly , when a database is defined in SVRGROUP of the Tmax configuration file.
Checklist for DBMS
The following is a DBMS integration checklist.
-
Check the installation of the client module provided by the DBMS vendor.
-
Database related items - Check the number of sessions allowed per client.
-
The development tool module required to create a Tmax server application is required.
-
Check the XA / Non-XA settings.
The use of XA mode must be determined at the application design phase. XA and Non-XA can be divided based on the distributed transaction processing technique and the connections between the DBMS and the Tmax system.
Mode Description XA A DBMS connection is established based on the Tmax configuration file. X/OPEN ATMI functions are used to commit or roll back XA transactions, and the relevant processes are completed through TMS. Non-XA DBMS connections, transaction commits, and rollbacks are processed via the developer's ESQL statement.
In XA mode, the TMS server provided by Tmax manages transactions.
Tmax regards all transactions as global transactions and uses 2PC (Two Phase Commit) to ensure data integrity. A separate configuration for connections to the resource manager must be defined in the Tmax configuration file. Transactions are managed using the Tmax API, which is necessary when processing databases in a distributed environment. The following is the program processing algorithm in XA mode.
A separate logic for connecting to (and disconnecting from) the
database is not necessary for tpsvrinit() / tpsvrdone() logic. Similar
to Non-XA mode, when a Tmax server application is booted through
tmboot, the Tmax system establishes a connection to
the database. TMS, which manages commits and rollbacks of global
transactions, also connects to the database. Any commit, rollback, or
rollback cancellation requests of a global transaction must be made via
the TX API of the Tmax system or according to the Tmax configuration
file settings. To enable XA mode, check the server group, which includes
the server application to be connected to DBMS in the SVRGROUP section
of Tmax configuration file, and specify the XA setting for the server
group.
The following is the SVRGROUP section configuration in XA mode.
*SVRGROUP
svg1 NODENAME = tmax,
DBNAME = ORACLE,
OPENINFO = "ORACLE_XA+Acc=P/scott/tiger+SesTm=600",
TMSNAME = svg1_tms
*SERVER
svr1 SVGNAME = svg1
Note
For more information about server group configuration environment, refer to "Tmax Administrator's Guide".
The Tmax system in Non-XA mode allows each application to directly send a transaction command to the resource manager, but cannot be used for global transactions in the distributed environment. An additional setting is required to enable Non-XA mode. Non-XA mode is available by writing applications to directly connect to RDBMS and defining transactions in each application.
Non-XA mode adopts a server program mode that uses native SQL, and has transaction control linked to the RDBMS. Non-XA mode can only use local transactions. Server programs running in Non-XA mode are suitable for executing simple Select queries or time consuming batch server programs. Non-XA mode can specify transaction range and control only for a direct connection between Non-XA mode user applications and the RDBMS. Tmax is not involved in this action.
Two points distinguish Non-XA mode from XA mode.
-
SQL in the user application controls the connection with the RDBMS.
-
Server programs can request transactions but client programs cannot. It is recommended that tpsvrinit() be used to connect to a database and tpsvrdone() be used to disconnect from a database.
The following is the program processing order in Non-XA mode.
-
Create the logic to access the DBMS in the tpsvrinit().
-
Explicitly add DBMS access rollback or release logics to tpsvrdone().
-
When a Tmax server application is booted through
tmbootortmboot -S svrname, a connection is established between the DBMS and the Tmax server application process. -
After a connection is established, the service logic can send a transaction request, commit, or rollback the transaction via ESQL.
The following is the SVRGROUP section configuration in Non-XA mode.
*SVRGROUP svg1 NODENAME = tmax *SERVER svr1 SVGNAME = svg1
Note
For more information about transaction-related functions, refer to "9.9. Transaction Management" or "Tmax Reference Guide".
Transaction errors include TX and XA-related errors.
TX-related errors are defined in <usrinc/tx.h>, while XA-related errors are defined by database vendors. For Oracle related errors, see <$ORACLE_HOME/rdbms/demo/xa.h>.
The following is a list of transaction errors.
| Error Code | Description |
|---|---|
| TX_NOT_SUPPORTED(1) | Mode does not support transactions. |
| TX_OK(0) | Transaction completed successfully. |
| TX_OUTSIDE(-1) | Local transaction is being processed. |
| TX_ROLLBACK(-2) | commit cannot be executed. The
transaction is rolled back. |
| TX_MIXED(-3) | A part was committed and a part was rolled back. |
| TX_HAZARD(-4) | Transaction did not complete successfully. |
| TX_PROTOCOL_ERROR(-5) | Transaction was called abnormally. |
| TX_ERROR(-6) | Error occurred in the database. |
| TX_FAIL(-7) | Critical error occurred. |
| TX_EINVAL(-8) | Invalid parameter was received. |
| TX_COMMITTED(-9) | Transaction was performed on a database independently. |
| TX_NO_BEGIN(-10) | Transaction was committed but a new transaction cannot be started. |
The following is a list of XA errors.
| Error Code | Description |
|---|---|
| XA_OK(0) | Transaction completed successfully. |
| XAER_RMERR(-3) | Resource Manager error set in the configured OPENINFO section. |
| XAER_NOTA(-4) | XID is invalid. |
| XAER_INVAL(-5) | Invalid parameter was received. |
| XAER_PROTO(-6) | Transaction called at an improper stage. |
| XAER_RMFAIL(-7) | Failed to connect to database. |
| XAER_DUPID(-8) | Previously assigned XID is used. |
| XAER_OUTSIDE(-9) | Transaction is out of transaction mode. |