Transaction Processing Monitors

An Overview

Module 2COP 6730

2

Overview

• A reference architecture of transaction-oriented system

• role of a TP monitor within this framework.

– services provided by a TP monitor

– structure of this system component

3

The Role of TP MonitorsOperating systems, communication systems, etc. are usually not designed for the needs of a transaction-oriented environment:

– A TP monitor provides

• either essential services absent from the host system, or

• services the host performed so poorly that a new implementation was required.

– The main function of a TP monitor is to integrate other system components to make them work together to support transaction-oriented processing.

4

Characteristics of TRANSACTION-ORINETED

PROCESSING (1)

Data sharing: Computations read and update databases shared among all users.

Repetitive workload: Users do not run arbitrary programs, but rather request the system to execute certain functions out of a predefined set.

Mostly simple functions: Consume 105 – 107

instructions and do some 10 disk I/Os.

Variable requests: exhibits some statistical regularity, but cannot be preplanned.

5

Characteristics of TRANSACTION-ORINETED

PROCESSING (2)Some batch transactions: have the size and

duration of typical batch jobs.

Many concurrent users: 103 – 106

High availability: Because of the large number of users, the system must be highly reliable and available.

System does recovery.

Automatic load balancing: The system should deliver high throughput with guaranteed low response time (soft real-time system).

Transaction Types

Transaction types are distinguished by three categories

– Direct vs queued

– Simple vs complex

– Local vs distributed

6

direct/queued

Simple/complex

loca

l/di

strib

uted

7

Direct vs Queued Transactions

Direct: The terminal and the process running the server program (handling the request) are associated with each other.

Queued: Transactions are put in a queue and scheduled for processing according to the queuing discipline.

ServerProgram

ServerProgram

8

Simple vs Complex Transactions

Simple

– Single message: There is a single input message from the terminal; and upon commit, a single output message is delivered.

– Short: The number of object it touches is in the tens.

Complex

– Conversational: It allows for repeated exchange of messages between the user and the application.

– Long: The number of objects it touches is in the tens of thousands (batch-like transaction).

Local vs Distributed Transactions

• Local: Transactions run entirely on the network node where the request originated (centralized processing).

• Distributed: In addition to the local node, transactions may also invoke services from other nodes

9

10

A TAXONOMY OF TRANSACTION EXECUTION

Transaction

Direct Queued

Single Message Conversational Short Long

Local Distributed Local Distributed Local Distribute Local Distribute

Direct OLTP Complex Online Queued OLTP Long Batch Transaction Transaction Transaction Transaction (e.g., ad hoc queries)OLTP: Online Transaction Processing

11

Transaction Processing Services

• Transaction services must provide a programming environment that integrates transaction control in a seamless manner.

– The program needs not worry about concurrency, failures, clean-up, and so forth.

• As far as data sharing is concerned, applications can use the services provided by a database service.

12

Transaction Processing Services

Manage heterogeneity: Local transaction mechanisms in each subsystem are not sufficient to ensure the ACID properties for the whole function.

Control communication: Status of communication sessions must also be subject to transaction control (e.g., Transactional RPC)

Terminal management: Since the ACID properties must be perceived by the user, sending and receiving the message must be part of the transaction (e.g., Response delivered to user before failure ?)

Presentation services: If the terminal uses sophisticate presentation services, then reestablishing the window environment after a crash is also a part of the transaction guarantee.

Context management: Storing and Recovering context must be bound to the SoC

Start/restart: TP monitor must also handle restart after any failure. By doing so, all the subsystems are brought up in a state that is consistent with respect to the ACID rules

Apart from the technical issue of access to shared data, more system services are required

13

Integrated Control

Note:

• All components integrated by the transaction services must implement a basic set of protocols that enable them to cooperate in transaction processing

• Subsystems that support these protocols are called resource managers

Database transactioncontrol is not all there

is to transactionprocessing

14

Server and Sever Class• Typically, a number of services are

bunched together in one application.

• Server class is a group of processes (servers) that are able to run the code of a given application program.

• At run time, a server class is maintained for each application program.

• Execution of a service request requires the request to be sent to a process (a server) of the right server class – service invocation.

15

One Process Per Terminal

• All applications are linked together to form one application program.

• At logon, each terminal is given its own process for the entire session (e.g., time-sharing systems)

100 Applications

Process

100 Applications

Process

100 Applications

Process

100 Applications

Process

16

One Process Per Terminal

Problem:

1. Too many capabilities per processor: Each process comes with more capabilities then a terminal needs.

2. Too many process switches: Process switches are very expensive operations in most operating systems (2,000 – 5,000 instructions)

Limitation: Acceptable only for small systems of less than 200 clients.

17

Only One Terminal Process

•All terminals talk to one process which can be the TP monitor process itself.

100 Applications

One Process

• The TP monitor process receives the function requests and route them to the programs that can service them

EXAMPLE: CICS (Customer Information Control System) is a transaction server that runs primarily on IBM mainframe systems.

18

Only One Terminal Process

Advantages & Disadvantages• Advantages:

– Makes transaction processing simpler.

– The TP monitor can check the function requests, schedule them according to its own polices, and so on.

• Disadvantages:

– Each page fault or other exception in the process will stop the whole TP environment.

– Since a single process can employ only one CPU at a time, the TP system can uses only one CPU.

– The process is confined within one address space, which can be a serious limitation for large application.

19

Many Servers, One Scheduler

• One (data communication) process handles all request and response messages.

• There is a group of processes (i.e., a server class) for each application program.– Different applications are fenced off against each

other.– The data communication process routes the service

request to the appropriates server.

20

Many Servers, One Scheduler

Advantages & Disadvantages• Example: IMS/DC

IMS (Information Management System) is a joint hierarchical database and information management system with extensive transaction processing capabilities

• Advantages: Simplicity! There is one place for scheduling and load control.

• Disadvantages: The data communication resource can become a bottleneck.

21

Many Servers, Many Schedulers

A number of (functionally identical) data communication processes do the terminal handling

– There is a server class for data communication services.

– The communication service must multiplex itself among the terminals it is attached to (i.e., multi-threaded process).

Application 1

Application n

Many DataCommunication

ProcessesMany

ApplicationServersTerminals

MonitorProcess

22

Many Servers, Many Schedulers

• The application server classes are set up as in “many servers one scheduler” scenario.

• The application servers can be simple, single-threaded processes.

The presentation service process should be multi-threaded to support multiple terminals

Load control, activation/deactivation of processes, etc. must be coordinated by a separate instance, the monitor process

23

Many Servers, Many Schedulers

Advantages & DisadvantagesExample: Tandem’s Pathway, DEC’s ACMS

(Application Control Management System).

Advantage:

•The data communication process is no longer a bottleneck.

•Expensive process switches can generally be replaced by much cheaper process-internal thread changes.

Disadvantage: Load balance become more difficult.

24

Tasks of TP Monitors (1)

• Scheduling: Service requests must be mapped to the proper servers.

• Server class management: The TP monitor is responsible for setting up the server class.

• Recovery: After a crash, the TP monitor is responsible for bringing up the TP environment.

– It starts all the system processes,

– brings up the server classes, and then

– passes control to the transaction manager.

25

The Tasks of TP Monitors (2)

• Resource administration: Information about the terminals, databases, application programs, users, etc. is kept in a system repository managed by the TP monitor.

• Authentication and authorization: Service requests must be cleared by the TP monitor before they are executed.

• System operation: The TP monitor must

– provide the operators with sufficient information to tune the system, and

– inform them about any problems that occur during normal operations.

26

Resource ManagersA resource manager is a software subsystem that ties into the TP monitor to provide protected actions on its state.

It must be able to participate in transaction-oriented recovery

TRID: used to tag all subsequent messages

BEGIN WORKreceive (input message)< some SQL >send (statistics menu) to (window w1);COMMIT WORK;

Many server, one scheduler

DB2 participate in transaction

DB2 participate in transaction

Start SoCStart SoC

27

Context-Sensitive Scheduling

• The completion of a request typically frees the server so that it can be reassigned to another request.

• However, there are cases in which a server is reserved for a special user.

Example: For chained transactions, the server must be reserved for the “next” transaction, because it may refer to local context variables available only in that server process.

28

Transaction Manager (TM)

Once the transaction program has started, TP monitor has little to do with transaction management.

The coordination of the resource mangers is done by the transaction manager.

29

Transaction Manager (TM) cont’

We want to separate

•the components exercising transaction control (transaction manager) from

•those that do transaction-oriented resource scheduling (TP monitor).

Reasons: There are transactions that do not come in though the TP monitor.

Examples:• Ad hoc query interface of SQL system.• CAD applications run their own terminal

environment.

DBMSTP Environment

Query

30

Responsibilities of TP Monitors (1)

• The TP monitor brings up the resource managers upon startup.

• For restart, the TP monitor only has to bring up the resource managers.

The actual recovery protocol is completely handled among the resource managers and the transactions manager.

31

Responsibilities of TP Monitors (2)

• To dispatch a server for a request, the TP monitor creates a process (or reuse an existing one) and load the code into it.

• All the calls among resource managers are so-called transactional remote procedure calls (TRPCs). The mechanisms to handle them are provided by the TP monitor.

Example: BEGIN_WORK is a TRPC to the transaction manager.

Transactional Remote Procedure Call

(TRPC)

33

Remote Procedure Call (RPC)

A RPC system enables

a client program to communicate with sever programs on different computers by calling procedures in a similar way to the conventional use of procedure calls in high-level language.

Serverprogram

Clientprogram

Computer 2Computer 1

Serverprogram

34

Export/Import Service

Procedure 1

Procedure 2

Procedure 3

Resource

ServerClient

Export myprocedures

– Export Procedures: At the RPC level a service may be viewed as a module with an interface that exports a set of procedures appropriate for operating on some data abstraction or resource.

35

Export/Import Service

Procedure 1

Procedure 2

Procedure 3

Resource

ServerClient

– Import Procedures: From the perspective of client programs, a service provides the same facilities as a software module – enabling clients to import its procedures.

Import aprocedure

36

Marshalling• Marshalling is the process of taking a collection

of data items and assembling them into a form suitable for transmission in a message.

– Flatten structured data items into a sequence of basic data items.

– Translate those data items into an external data representation.

Mar

shal

ling

37

Unmarshalling• Unmarshalling is the process of

disassembling them on arrival to produce an equivalent collection of data items at the destination.

– Translate the external data representation to the local one.

– Unflatten the data item.

Mar

shal

ling

Unm

arsh

allin

g

38

Message Destinations•Potential clients need to know an identifier for

communicating with a server.

•In the Internet protocols, the destination addresses for messages are specified as – a port number used by a process and – the Internet address of the computer on which it

runs.

Send(p, message)

Receive(p, message)port p

port q

Message

Internet Address

39

RPC: Main TasksThe software that supports remote procedure calling has three main tasks:

– Binding: Locating an appropriate server for a particular service.

– Communication handling: Transmitting and receiving request and reply messages.

– Interface processing: Integrating the RPC mechanism with client and server programs in convention programming languages.

• dispatching of request messages to the appropriate procedure in the server.

• marshalling and unmarshalling of arguments in the client and the server.

40

Stub Procedure

An RPC system provides a stub procedure to stand in for each remote procedure that is called by the client program.

Client computer Server computer

Client process Server process

Localcall

Localreturn

ReceiveRequest

Selectprocedure

SendReply

Sendrequest

ReceiveReply

Executeprocedure

Return

Unmarshallarguments

Marshallresults

Marshallarguments

Unmarshallresults

Client Client stubprocedure

Communicationmodule

Communicationmodule

Dispatcher Server stub

Serviceprocedure

41

Client Stub Procedure

The purpose of a client stub procedure is to convert a local procedure call to a remote procedure call to the server.

– marshal the arguments and to pack them up with the procedure identifier into message,

– send the message to the server and then await the reply message,

– unmarshal it and return the results.

Client computer

Client process

Localcall

Localreturn

Sendrequest

ReceiveReply

Marshallarguments

Unmarshallresults

Client Client stubprocedure

Communicationmodule

42

Server Stub Procedure

Despatcher: uses the procedure identifier in the request message to select one of the server stub procedures and pass on the arguments.

Server stub procedure:– unmarshals the arguments,– calls the appropriate service

procedure, and– when it returns, marshals

the output arguments into a reply message.

An RPC system provides a despatcher and a set of server stub procedures.

Server computer

Server process

ReceiveRequest

Selectprocedure

SendReply

Executeprocedure

Return

Unmarshallarguments

Marshallresults

Dispatcher Server stub

Serviceprocedure

43

Remote Procedure Calls (RPCs)

• RPC makes the invocation of services at remote nodes look like local subroutine calls.

• The RPC stub on the callee acts fully complementary to the stub at the caller’s side.

CALLER (client) CALLEE (server)

RPC stub

RPC stub

:

Procedure Call

:

Service Routine

1. Subroutine Call

2. Request massage

3. Subroutine Call

44

Interface Definition• The types of the arguments and results

in the client stub must conform to those expected by the server stub. This is achieved by the use of a common interface definition.

• An RPC interface definition specifies those characteristics of the procedures provided by a server that are visible to the server’s clients:

– names of the procedures, and

– types of their parameters.

45

Interface Compilers

Interface compilers can be designed to process interfaces for use with different languages enabling clients and servers written in different languages to communicate by using RPCs.

Interface Definition(in Interface Definition Language)

INTERFACE COMPILER A INTERFACE COMPILER B

Client stub Server stubClient

programServer

programDispatcher

COMPILER A COMPILER BCOMPILER BCOMPILER BCOMPILER A

LINKER LINKER

CLIENT SERVERRPC

Client computer Server computer

Client process Server process

Localcall

Localreturn

ReceiveRequest

Selectprocedure

SendReply

Sendrequest

ReceiveReply

Executeprocedure

Return

Unmarshallarguments

Marshallresults

Marshallarguments

Unmarshallresults

46

Interface Compilers

Interface compilers can be designed to process interfaces for use with different languages enabling clients and servers written in different languages to communicate by using RPCs.

Interface Definition(in Interface Definition Language)

INTERFACE COMPILER A INTERFACE COMPILER B

Client stub Server stubClient

programServer

programDispatcher

COMPILER A COMPILER BCOMPILER BCOMPILER BCOMPILER A

LINKER LINKER

CLIENT SERVERRPC

47

Invocation of SQL Resource Manager

(SQL Pre-compiler)1. Server Side: SQL pre-compiler parses and

translates the SQL statement into an internal representation that can be interpreted directly by the SQL executor.

2. Client Side: The pre-compiler also generates code for the host language to call the SQL server:

!sqlselect(‘fastsql’, format_CB, expression_CB, &variable_CB);

A resource manager invocation (recognized by the stub compiler) Entry

point

Resource manager name (RMNAME)

Parameters

SELECT …FROM …WHERE …

Precompiler QueryExecutor

Internal representation

Internal representation

48

Invocation of SQL Resource Manager

(SQL Pre-compiler)1. Server Side: SQL pre-compiler parses and

translates the SQL statement into an internal representation that can be interpreted directly by the SQL executor.

2. Client Side: The pre-compiler also generates code for the host language to call the SQL server:

!sqlselect(‘fastsql’, format_CB, expression_CB, &variable_CB);

A resource manager invocation (recognized by the stub compiler) Entry

point

Resource manager name (RMNAME)

Parameters

In host language

49

Execution Plans

• At compile time, the client has to issue rmCall to the SQL server for it to compile the statement.

• The SQL server compiles the statement and generates the access plan, and hands back an ID for that plan.

• At run time, the rmCalls from the client refer to the access plan ID and thereby ask the server to run that pre-compiled query.

Embedded SQL is compiled once, and from then on the generated query plan is executed.

50

BindingAn interface definition specifies a textual service name for a server. However, client request message must be addressed to a server port.

SERVERCLIENT

@ th

is se

rver

por

t

Look

up

serv

ice

Register service

name

& server port

Binder(Name Service)

Service Name Server Port

Registration: When a server process starts executing, it sends a message to the binder requesting it to register its service name and server port.

Look Up: When a client process starts, it sends a message to the binder requesting it to look up the identifier of the server port of a named service.

51

Transactional RPC (TRPC)

• Bind RPCs to transaction: Each RPC is tagged with a TRID.

• Inform the transaction manager: It makes sure that the transaction manager knows the callee is participating in a transaction (i.e., expanding the sphere of control).

• Binding Processes to transactions: When dispatching a server, the TP monitor remembers the transaction for which the server is running and thus can inform the transaction manager if that process crashes.

TP Monitors provide the mechanism to handle RPCs. In addition, TP monitors turn each RPC into a TRPC:

52

TP Monitors & O.S.

TP monitors allocate resources for other system components to do the work, rather then doing the work itself.

– Their tasks are similar to the duties of an operating system.

– Some believe it would be best if the operating system just swallowed the TP monitor.

53

Summary

The sum of TP monitor’s functioning is twofold:

1. It extends standard RPC mechanisms to include server class management.

2. It provides the transaction manager with enough information to keep the dynamically expanding web of resource managers participating in a transaction within a sphere of control.

54

Dynamic of TRPC (1)

1. Bind the RMNAME in the invocation to a NODEID and an RMID; information is obtained from the name server.

2. Look up the callee’s interface prototype description (in the repository).

3. Coerce* the local parameter representation into the one expected by the invoked resource manager.

4. Pack all the transformed parameter values into a byte string (parameter marshalling).

*e.g., mapping the data type from Big Endian (most significant byte in smallest address) to Little Endian (least significant byte in smallest address)

55

Dynamic of TRPC (2)5. Send the message to the peer TRPC stub.

6. The caller is now suspended until the response from the server arrives.

7. When the response from the server arrives, unpack the byte string (reveres marshalling).

8. Coerce the parameter values received into the representation used by the caller.

Note:

Client makes it right: coercing the parameter values is done at the caller’s site.

Server makes it right: coercing is done at the server’s site.