Introduction
- Definition: TP monitors are systems initially developed to support a large number of remote terminals (e.g., airline reservation systems) from a single computer. They have evolved to provide core support for distributed transaction processing.
- Original Term: “Teleprocessing monitor”
- Evolution: Now primarily support distributed transaction processing.
- Examples CICS TP monitor (IBM, very widely used), Oracle Tuxedo, Microsoft Transaction Server.
- TP lite: Web application server architectures(Servlets).
26.1.1 TP-Monitor Architectures
- Fundamental Design: Client-server architecture.
- Goal: Efficiently handle a high volume of transactions from many clients, ensuring data consistency and reliability.
Architectural Models
Process-per-Client Model
- Description: A separate server process is created for each client connection. The server handles authentication and executes client requests.
- Diagram Description (Figure 26.1a): Shows multiple remote clients, each connected to a dedicated server process. All server processes interact with shared files and a database.
- Problems:
- High Memory Requirements: Each process consumes memory for local data, file descriptors, and operating system overhead (e.g., page tables).
- High Context Switching Overhead: The operating system’s multitasking (switching between processes) incurs significant CPU overhead. A context switch can take hundreds of microseconds.
Single-Server Model
- Description: A single server process handles all client connections. The server manages authentication and request execution.
- Diagram Description (Figure 26.1b): Shows multiple remote clients all connecting to a single server process, which then interacts with files and a database.
- Improvement: Reduces memory overhead and context switching compared to the process-per-client model.
- Multithreading: The server process is multithreaded to handle multiple clients concurrently. Each client has its own thread of control.
- Low-Overhead Multitasking: Switching between threads within a process is much faster (microseconds) than switching between processes.
- Examples: Original IBM CICS, Novel’s NetWare.
- Problems:
- Lack of Protection: All applications run within a single process, so a bug in one application can crash the entire system or affect other applications.
- Not Suitable for Parallel/Distributed Databases: A single server process cannot easily be distributed across multiple computers.
Many-Server, Single-Router Model
- Description: Multiple application server processes access a common database. A single communication process (router) routes client requests to the appropriate server.
- Diagram Description (Figure 26.1c): Shows multiple remote clients connecting to a single router. The router directs requests to one of several server processes, which then interact with files and a database.
- Benefits:
- Supports Multiple Applications: Different server processes can handle different applications.
- Server Pools: Each application can have a pool of servers. Requests can be routed to the least loaded server.
- Multithreaded Servers: Each server can still be multithreaded to handle multiple clients.
- Scalability: The application server can be run on different sites of a parallel or distributed database.
- Web Server Analogy: Widely used in web servers. A main process receives HTTP requests and assigns them to a process from a pool. Each process is often multithreaded.
- Safe Languages Use of language such as Java, C# or visual basic allows web application servers to protect threads from errors in other thread.
Many-Server, Many-Router Model
- Description: Multiple communication processes (routers) handle client connections, and each router can route requests to multiple server processes.
- Diagram Description (Figure 26.1d): Shows multiple remote clients connecting to multiple routers. Each router can direct requests to any of several server processes, which then interact with files and a database. A “monitor” process oversees the entire system.
- Benefits:
- Higher Scalability and Availability: Handles even larger numbers of clients and servers. Failure of one router does not bring down the entire system.
- Controller Process: A controller process manages startup and supervision of other processes.
- Web Server Analogy: Used in very high-performance web server systems. Routers can be network routers directing traffic to different servers based on origin.
Components of a TP Monitor (Detailed in Figure 26.2)
- Diagram Description Shows a central block labeled ‘network’, from which an arrow leads to a box labelled ‘input queue’, subsequent arrows link this to ‘authorization’,‘lock manager’, ‘recovery manager’, ‘log manager’, ‘application servers’, and, ‘database and resource managers’. Lastly, an arrow directs to a box called ‘output queue’
- Input Queue: Incoming client requests are placed in a queue.
- Durable Queue: The queue may be durable, meaning its entries survive system failures. This ensures that requests are processed eventually, even after a crash.
- Authorization: Handles user authentication and access control.
- Application Server Management: Starts up servers, routes messages to servers, and manages server pools.
- Lock Manager: Provides concurrency control to ensure data consistency.
- Recovery Manager: Handles transaction recovery in case of failures.
- Log Manager: Manages the transaction log, which is used for recovery.
- Output Queue: Handles outgoing messages to clients.
- Database and Resource Managers: Provides access to databases and other resources.
- Persistent Messaging Support: Guarantees that messages are delivered if (and only if) the associated transaction commits (Section 19.4.3).
- Presentation facilities Provide menues for dumb terminals.
26.1.2 Application Coordination Using TP Monitors
- Challenge: Modern applications often interact with multiple databases, legacy systems, and communication subsystems. Transactions must be coordinated across these systems.
- TP Monitor Role: TP monitors provide support for building and administering such complex applications.
Key Concepts
Resource Manager:
Each subsystem (database, legacy system, etc.) is treated as a resource manager.
- Definition: A resource manager provides transactional access to a set of resources.
- Interface: The TP monitor interacts with resource managers through a defined set of transaction primitives:
- (for two-phase commit)
- Other Services: Resource managers also provide other services, such as data access, to the application.
X/Open Distributed Transaction Processing (DTP) Standard:
- Purpose: Defines a standard interface for resource managers.
- Benefit: Allows TP monitors and other X/Open-compliant systems to interoperate with various resource managers (including databases).
- It includes XA interface.
Two-Phase Commit (2PC):
- TP Monitor as Coordinator: The TP monitor can act as the coordinator for two-phase commit when transactions access multiple resource managers (databases, durable queues, persistent messaging).
- Ensures Atomicity: Guarantees that either all participating resource managers commit or all abort, even in the presence of failures.
Other TP Monitor Functions in Complex Systems:
- System Checkpoints and Shutdowns: Coordinates these activities.
- Security and Authentication: Manages client authentication.
- Server Pool Administration: Adds or removes servers without interrupting the system.
- Failure Handling:
- Server Failure: Detects server failures, aborts in-progress transactions, and restarts them.
- Node Failure: Migrates transactions to other servers, backs out incomplete transactions.
- Node Recovery: Manages the recovery of failed nodes.
- Failure Hiding in Replicated Systems: Can transparently route requests to backup replicas if a primary site fails (e.g., remote backup systems - Section 16.9).
Transactional Remote Procedure Call
- It is used in client server system.
- RPC mechanism provides calls to enclose series of RPC calls with in a transaction.