One way to solve these problems is to run multiple application-server processes that access a common database, and to let the clients communicate with the application through a single communication process that routes requests. (However, concurrent threads within a process can be supported in a shared-memory multiprocessor system.) This is a serious drawback in large organizations, where parallel processing is critical for handling large workloads, and distributed data are becoming increasingly common.
#LARGE TRANSACTION PROCESSING SYSTEM FULL#
Unlike the overhead of full multitasking, the cost of switching between threads is low (typically only a few microseconds).
#LARGE TRANSACTION PROCESSING SYSTEM CODE#
It executes code on behalf of one client for a while, then saves the internal context and switches to the code for another client. To avoid blocking other clients when processing a long request for one client, the server process is multithreaded: The server process has a thread of control for each client, and, in effect, implements its own low-overhead multitasking. The server process handles tasks, such as user authentication, that would normally be handled by the operating system. This model is also used in client–server environments, where clients send requests to a single-server process. Remote clients send requests to the server process, which then executes those requests. The above problems can be avoided by having a single-server process to which all remote clients connect this model is called the single-server model, illustrated in Figure b. Each context switch between one process and the next has considerable CPU overhead even on today’s fast systems, a context switch can take hundreds of microseconds. The operating system divides up available CPU time among processes by switching among them this technique is called multitasking.Even if memory for program code is shared by all processes, each process consumes memory for local data and open file descriptors, as well as for operating-system overhead, such as page tables to support virtual memory. Per-process memory requirements are high.This model presents several problems with respect to memory utilization and processing speed: This process-per-client model is illustrated in Figure a.
One way of building such systems is to have a server process for each client the server performs authentication, and then executes actions requested by the client. Large-scale transaction processing systems are built around a client–server architecture. Current-generation TP monitors include Tuxedo and Top End (both now from BEA Systems), Encina (from Transarc, which is now a part of IBM), and Transaction Server (from Microsoft). The CICS TP monitor from IBM was one of the earliest TP monitors, and has been very widely used. TP monitors have since evolved to provide the core support for distributed transaction processing, and the term TP monitor has acquired its current meaning. The term TP monitor initially stood for teleprocessing monitor. Transaction-processing monitors (TP monitors) are systems that were developed in the 1970s and 1980s, initially in response to a need to support a large number of remote terminals (such as airline-reservation terminals) from a single computer. In this chapter, we go beyond the basic schemes discussed previously, and cover advanced transaction-processing concepts, including transaction-processing monitors, transactional workflows, main-memory databases, real-time databases, longduration transactions, nested transactions, and multidatabase transactions. We discussed in those chapters a variety of schemes for ensuring the ACID properties in an environment where failure can occur, and where the transactions may run concurrently. In Transactions ,Concurrency Control and Recovery system, we introduced the concept of a transaction, which is a program unit that accesses and possibly updates various data items, and whose execution ensures the preservation of the ACID properties.
0 kommentar(er)
