Transaction Processing Monitors
A transaction processing monitor (TPM) is a program that monitors transactions from one stage to the next, ensuring that each one completes successfully; if not, or if an error occurs, the TM Monitor takes the appropriate action. A transaction processing monitor’s main purpose/objective is to allow resource sharing and assure optimal use of the resources by applications. This term is sometimes shortened to TP monitor.
A transaction processing monitor is critical in multi-tier architectures. With processes running on different platforms, a given transaction may be forwarded to any one of several servers. Generally, the TP monitor handles all load balancing. After completing each transaction, the TPM can process another transaction without being influenced by the prior transaction. In other words the TPM model essentially is stateless.
Transaction Processing Monitor architecture
In the TP Monitor Architecture, ACID transactions are initiated by a Begin-Transaction call and terminated by either a Commit-Transaction or an Abort-Transaction call. When initiated, each transaction is assigned a unique identiier and entered into a transaction table managed by the Transaction Manager. Each entry in the transaction table contains the transaction identiier (TRID), the transaction status, and other information. When a transaction calls a transaction control operation, such as Commit-Transaction, the Transaction Manager is responsible for carrying out the execution of the command and recording information in the transaction table.
- Process per client model - instead of individual login session per terminal, server process communicates with the terminal, handles authentication, and executes actions.
- Single process model - all remote terminals connect to a single server process. Used in client-server environments.
- Many-server single-router model - multiple application server processes access a common database; clients communicate with the application through a single communication process that routes requests.
- Many server many-router model - multiple processes communicate with clients.
In general, a TPM provides the following functionality:
- Coordinating resources
- Balancing loads
- Creating new processes as/when needed
- Providing secure access to services
- Routing services
- Wrapping data messages into messages
- Unwrapping messages into data packets/structures
- Monitoring operations/transactions
- Managing queues
- Handling errors through such actions as process restarting
- Hiding interprocess communications details from programmers
Vendors Transaction Processing Monitors
F.A.Q about Transaction Processing Monitors
Advantages of TP Monitors
Complex applications are often built on top of several resource managers (such as DBMSs, operating systems, user interfaces, and messaging software). A TPM is a middleware component that provides access to the services of a number of resource managers and provides a uniform interface for programmers who are developing transactional software.
- Transaction routing the TP Monitor can increase scalability by directing transactions to specific DBMSs.
- Managing distributed transactions the TP Monitor can manage transactions that require access to data held in multiple, possibly heterogeneous, DBMSs. For example, a transaction my require to update data items held in an Oracle DBMS at site 1, an Informix DBMS at site 2,and an IMS DBMS at site 3. TP Monitors normally control transactions using the X/Open Distributed Transactions Processing (DTP) standard. A DBMS that supports this standard can function as a resource manager under the control of a TP Monitor acting as a transaction manager.
- Load balancing the TP Monitor can balance client requests across multiple DBMSs on one or more computers by directing client service calls to the least loaded server. In addition, it can dynamically bring in additional DBMSs as required to provide the necessary performance.
- Funnelling in environments with a large number of users, it may sometimes be difficult for all users to be logged on simultaneously to the DBMS. In many cases, we would find that users generally do not need continuous access to the DBMS. Instead of each user connecting to the DBMS, the TP Monitor can establish connections with the DBMSs as and when required, and can funnel user requests through these connections. This allows a larger number of users to access the available DBMSs with a potentially much smaller number of connections, which in turn would mean less resource usage.
- Increased reliability the TP Monitor acts as a transaction manager, performing the necessary actions to maintain the consistency of the database, with the DBMS acting as a resource manager. If the DBMS fails, the TP Monitor may be able to resubmit the transaction to another DBMS or can hold the transaction until the DBMS becomes available again.
TP Monitors are typically used in environments with a very high volume of transactions, where the TP Monitor can be used to offload processes from the DBMS server. Prominent examples of TP Monitors include CICS and Encina from IBM (which are primarily used on IBM AIX or Windows NT and bundled now in the IBM TXSeries) and Tuxedo from BEA Systems.