Lesson 7 | Transaction processors |
Objective | Describe the function of transaction processors. |
Understanding Transaction Processors in Middleware
In this comprehensive guide, we will delve into the world of transaction processors within the context of middleware. We will discuss the role of transaction processors, the different types available, and the importance of transaction management in middleware systems. By the end of this article, you will have a deep understanding of transaction processors and how they contribute to the efficient functioning of middleware.
Transaction processors (TPs), also called TP monitors, are one of the oldest forms of middleware. Transaction processors provide execution and management environments for transactions, here defined as logical units of process that serve a specific business function. TPs also manage the interoperability of transactions. The primary purpose of TPs is to ensure that transactions are processed to completion, or to take appropriate actions if an error occurs. TPs are especially important in
three-tier architectures[1] that employ load balancing. Why?
In the three-tier model, a transaction may be forwarded to any of several servers. TPs can offer load-balancing operations, forwarding transactions to different servers based on their availability. TPs therefore provide a number of important services: security, availability, and transaction handling. One of the first transaction processors was IBM's CICs, which is discussed below.
The Role of Transaction Processors
Transaction processors are the core components in middleware systems that manage the execution of transactions. They ensure that transactions are executed in a consistent, reliable, and efficient manner, adhering to the ACID properties (Atomicity, Consistency, Isolation, and Durability). Transaction processors are responsible for coordinating the actions of multiple distributed resources, such as databases, message queues, and other application services.
Types of Transaction Processors
There are different types of transaction processors, which primarily differ in the protocols they use to coordinate and commit transactions. Two of the most commonly used protocols are the Two-Phase Commit Protocol and the Three-Phase Commit Protocol.
Two-Phase Commit Protocol
The Two-Phase Commit Protocol (2PC) is a distributed transaction protocol that ensures the atomicity and consistency of transactions across multiple resources. It comprises two phases: the prepare phase and the commit phase.
- Prepare Phase: The transaction coordinator sends a prepare message to all involved resources, requesting them to prepare for the transaction. Each resource locks the data and verifies if it can commit the transaction. If a resource is ready to commit, it sends an "agree" message back to the coordinator, otherwise, it sends an "abort" message.
- Commit Phase: If all resources send an "agree" message, the coordinator sends a commit message, and each resource commits the transaction. If any resource sends an "abort" message, the coordinator sends a rollback message, and each resource rolls back the transaction.
Three-Phase Commit Protocol
The Three-Phase Commit Protocol (3PC) is an extension of the 2PC protocol that aims to address some of its limitations, such as vulnerability to network partitions and single point of failure. The 3PC protocol has an additional phase called the pre-commit phase, which occurs between the prepare and commit phases.
- Prepare Phase: Similar to 2PC, the transaction coordinator sends a prepare message to all involved resources, requesting them to prepare for the transaction.
- Pre-Commit Phase: If all resources send an "agree" message, the coordinator sends a pre-commit message. Each resource acknowledges the pre-commit message and awaits the final commit or abort message from the coordinator.
- Commit Phase: If all resources send an "acknowledge" message, the coordinator sends a commit message, and each resource commits the transaction. If any resource fails to acknowledge, the coordinator sends an abort message, and each resource rolls back
CICS and Transaction Processor
Short for Customer Information Control System, CICS was originally developed to provide transaction processing for IBM mainframes. CICS controls the interaction between applications and users and lets programmers develop screen displays without detailed knowledge of the terminals being used. CICS is also available on non-mainframe platforms. For practically any major eBusiness project taken on by the Fortune 1000, there will probably be a need to integrate with a CICS-based application. CICS is seldom used, however, as the core transacting software for modern eBusiness.
Question: What is the primary purpose of Transaction Processors?
Answer:To ensure that transactions process to proper completion or to take appropriate actions of they are not.
Transaction Processor Considerations
The predominant consideration here is age. Because TPs are the oldest form of middleware, transaction processing is a tried and true technology.
However, TPs have generally been supplanted by more robust and flexible integration technologies. Usually TPs are limited to a given computing architecture and a local set of programs. The need for cross-network and cross-application processing of calls for distributed object integration, XML, and message-based integration. In most cases, TP-based applications may be used to integrate into eBusiness applications, but seldom are they used as a core integration engine for eBusiness. The next lesson discusses a kind of middleware package, Enterprise Application Integration (EAI).
[1]
Three-tier architecture: A special type of client/server architecture consisting of three well-defined and separate processes, each running on a different platform.