Ch 6. Transaction Processing Monitors

1. Ch 6.Transaction Processing Monitors Dr. Kien A. Hua

2. Transaction Processing Monitor • Transactional RPC. • Functional Principles of the TP Monitor. • Managing Request and Response Queues. • Other tasks of TP Monitors • Load Balancing • Authentication and Authorization • Restart Processing

3. Layering of Services in a Transaction Processing System (1) • The Basic Operating System (BOS) uses the hardware directly. Examples: Process/Thread scheduling, file system, simple sessions, authentication, etc. • Transaction Processing Operating System (TPOS) uses BOS to provide a transactional programming environment. Examples: Server class, transaction manager, log, durable queue, transactional RPC, etc.

4. Layering of Services in a Transaction Processing System (2) • Transaction Processing Services (TRAPS) use both BOS and TPOS to create a transaction-oriented programming environment. Examples: Programming environment, load control, resource managers, databases, etc. • The application typically uses the TRAPS and TPOS, depending on the application's sophistication. Note: These layers do not reflect a strict implementation hierarchy. Rather, it describes a separation of concerns among different system components (e.g., TPOS can implement some of its data structures using SQL).

5. Coordination of Resource Managers (1) • Transaction control must be exercised over all resource manager interactions within one transaction. • The following are required for the “web” of a transaction’s calls to hang together: • Control of participants: • Someone must track which resource managers have been called. • At commit time, the transaction manager (TM) must go out and ask each resource manager involved whether they agree to successfully terminate the transaction.

6. Coordination of Resource Managers (2) • Preserving transaction-related information: • At commit each process running the same resource manager code is asked individually about its commit decision. • If the different invocations left their traces in different servers, the TRPC mechanism must provide a means to relate multiple invocations of the same resource manager to each other. • Support of the transaction protocol: • The resource managers must stick to the rules imposed by the ACID paradigm.

7. CALLBACK (1) • Each resource manager has a service interface that defines what the resource manager does for a living. • Furthermore, it declares a number of callback entries, which can be called when certain events happen. • If the RM maintains any durable objects, it must be able to accept rollback and prepare/commit callbacks from the TM. • The RM exports the callback entries to the transaction manager when it first checks in with the TP monitor. • The number of callback entries provided by a RM depends on its level of sophistication. Note: This can result in multiple threads executing the RM’s code at different entry points.

8. CALLBACK ENTRIES (1)

9. CALLBACK ENTRIES (2) The function prototype declares are shown below. Note that the invocation of a resource manager by the transaction manager at such callback entry is just another transactional remote procedure call. Boolean rm_Prepare(); /* invoked at phase 1 of commit. Returns vote. */ Boolean rm_Rollback_Savepoint (Savepoint); /* rollback to requested savepoint number */ /* TRUE if ok, FALSE if needs further rollback */ Boolean rm_Commit (Boolean); /* invoked at phase 2 commit; param is decision */ Boolean rm_Savepoint (); /* invoked when the transaction takes a savepoint */ /* TRUE if ok, FALSE if this resource manager */ /* cannot establish the savepoint and must */ /* continue rollback */ (void) rm_UNDO (&buffer); /* asks the resource mgr. to undo the effects */ /* described in the log record passed as parameter */ (void) rm_Abort (); /* invoked at end of abort phase */ /* after all undo steps have been performed */ (void) rm_REDO (&buffer); /* asks the resource mgr. to redo the effects */ /* described in the log rec. passed as a parameter */ (void) rm_Checkpoint (); /* invoked by TM for taking a check point */ (void) rm_restart (LSN); /* first callback from the transaction manager at */ /* restart; passes the address of the resource */ /* manager’s recent checkpoint record */

10. Installing a New Resource Manager (1) RMID rmInstall (RMNAME, &rm_callbacks, AccessControlList, stuff); /*other info. for TP monitor*/ • RMNAME is the user-supplied global external ID. • &rm_callback is an array of pointers to the callback entries. • These callback entries are specified as relative addresses in the load module for that RM. • The TP monitor keeps this array in the TRPC stub of the respective RM’s address space.

11. Installing a New Resource Manager (2) RMID rmInstall (RMNAME, &rm_callbacks, AccessControlList, stuff); /*other info. for TP monitor*/ • AccessControlList allows the TP monitor to check whether an incoming request for that RM is acceptable from a security point of view. • Stuff denotes remaining parameters: • The location from which the code for the resource manager can be loaded. • Which other resource managers need to be available before this one can start, etc.

12. Resource Manager’s Interfaces Fig 6.2: Overview of a resource manager’s interfaces. The resource manager both uses interfaces from other system components and provides interfaces to other system components. There are three groups to be distinguished: the interface the resource manager exports, the interfaces it uses from other general resource managers and the system resource manager interfaces it has to call to support the transaction protocol.

13. Resource Manager Sessions If a client C repeatedly invokes server class S, how should that be handled? We need to consider three scenarios.

14. Independent Invocations • A server class S can be called arbitrarily often, and the outcome of each call is independent of whether or not the server class has been called before. Example: • The server reads records from a database. • It performs some statistical computations on them, and returns the result. • Since the server keeps no state about the call, it can declares its consent to the transaction’s commit upon return.

15. Invocation Sequence • The client wants to issue requests that explicitly refer to earlier service requests. Example: The mini-batch example updates a number of records at a time (in a subtransaction) using a cursor. • The final decision of the server class depends on the outcome of the last invocation.

16. Complex Interaction • Each call to S is independent, except for some global integrity constraints that cannot be checked until commit and that may depend on the results of all previous invocations. • The server class must remember the results of all invocations by the client until commit.

17. Complex Interaction – Example Example: • A mail server stores the various parts of a message in a database. • It maintains a consistency constraint that says that all mails must have at least a header, a body and a trailer. There must be some way of relating all the updates done by the same client when the server is called (back) at rm_Prepare.

18. Implementing State Associated with a Client-Server Interaction • Context is maintained by a communication session. • Context is passed back and forth. • The servers write context information to a database. • The context is stored in a segment of shared memory for all servers of the same class. Context information about multiple invocations of the same server class can be maintained in four different ways:

19. Context Management: Communication Session • Such a session has to be managed by the TPOS. • All the client or the server has to do is to declare that it need one. • Typically, the request for a session is issued by the server. Applications do not want to be bothered with TPOS. • The price for this is considerable overhead in the TPOS for maintaining and recovering sessions.

20. Session Management If context maintenance is handled thru communication session, then the TP monitor is responsible for binding a server process to one client for the duration of a stateful invocation. typedef struct{ /* */ rmInstance EndA; /* one end of stateful interaction */ rmInstance EndB; /* other end of stateful interaction */ Uint SeqNo; /* sequence no. to distinguish between multiple */ /* stateful interactions among the same servers. */ } BindId; /* handler for a stateful interaction */ BindID rmBind (rmInstance); /* function passes the ID of the client to which a */ /* a session with the server has to be established. */ /* gets back a handle which identifies the interaction */ /* among this server and this client. */ /* returns the Null instance if binding fails. */ Boolean rmUnbind (BindID) /* inverse to rmBind, waives the future use of the */ /* specified binding, returns FALSE if no binding */ /* with that identifier was in effect */ Note: A BindID uniquely identifies an association between a client instance and a server instance.

21. Context Management Technique: Context Passing (1) • Context is passed back and forth explicitly between client and server upon each request and reply. This approach relieves the TPOS of the problem of context management.

22. Context Management Technique: Context Passing (2) • Since rm_Prepare call from the TM carries no context in its parameter list, the commit may have to be done as follows: • The client issue a “final” service call (with the “final” context), which tells the server that the client is about to call commit. • When the server returns normally, the client can call Commit_Work, and the server will not be called back by the TM.

23. Context Management Technique: Context Passing (3) Example: Global integrity constraints may depend on the result of all previous invocations.

24. Context Management Technique: Keep Context in Database (1) • The servers keep the context in a database. An arbitrary instance of the server can be invoked to vote on commit. • The state information must be supplied with the key attributes: • TRID • Client RMID • Sequence number of the invocation in order to uniquely identify which thread of control it belongs to.

25. Context Management Technique: Keep Context in Database (2) • Some of the work involved in maintaining the context can be off loaded to either an SQL database system or to the context management service of the TP monitor.

26. Context Management Technique: Shared Memory (1) • All servers of the same class share a segment of read/write memory in which invocation context is kept. • Synchronization on the shared memory is done by the server.

27. Context Management Technique: Shared Memory (2) • This scheme is similar to the solution using a context database, except that now the whole responsibility is with the server (class). Note: This solution is used by very sophisticated resource managers, such as SQL database systems.

28. Transaction-Oriented Context (1) • Client-Oriented Context: This reflects the state of an interaction between a client and a server. • In the last few pages, we assumed this type of context. • Transaction-Oriented Context: This type of context is bound to the SoC established by a transaction rather than to an isolated client-server interaction.

29. Server Class S1 time T1 time T2 Server Class C Server Class S3 Server Class S2 time T3 time T4 (needs the context established by the earlier call to S3 from S1) Transaction-Oriented Context (2) Note: The context needed by S3 is not bound to any of the previous client-server interactions, but it is bound to the transaction as such.

30. Transaction-Oriented Context (3) • A general context management scheme must be able to cope with both types of state information; that is, it must distinguish whether a piece of context is identified by the client-server interaction or by the TRID. • Each server that manages persistent objects must be implemented such that it can keep transaction-oriented context. • The TRPC mechanism must provide means for servers of any type to establish a stateful interaction with a client in case this should be needed (client-oriented context). • Note: Communication sessions can only be used to support client-oriented context. • (We will discuss transaction-oriented management techniques in more details later.)

31. Anchor of TPOS (1) • TPOS_Anchor is one well-defined point in the TPOS, from which all the system data structures can be reached. typedef struct anchor * TPOS_AnchorP; typedef struct anchor /* TPOS anchor for the global control blocks */ { ... TPAnchorP TPMonCBs; /* pointer to the anchor of the TP monitor */ TMAnchorP TM_CBs; /* pointer to the anchor of transaction mgr. */ CMAnchorP SM_CBs; /* pointer to the anchor of session mgr. */ LMAnchorP LM_CBs; /* pointer to the anchor of log mgr. */ IMAnchorP IM_CBs; /* pointer to the anchor of lock (isolation) mgr. */ } TPOS_Anchor;

32. Anchor of TPOS (2) • The declaration shows five system resource managers. This is a basic set; real systems might have more. • Each resource manager has its own local anchor, where this RM’s data structures are rooted. Note: Keeping the pointer to the anchors of system RMs in TPOS_Anchor ensures that addressability can be established in an orderly manner upon system startup. (This is necessary, because the TPOS comes up before any of the RMs is activated).

33. Anchors of System Resource Managers • The anchor of a system resource manager has no fixed layout. • The TP monitor’s anchor might have the following structure: typedef struct tpa * TPAnchorP; typedef struct tpa /* TP monitor anchor for its control blocks */ { char *MyVersion; /* version of the TP monitor running */ char Repository[64]; /* name of the repository I work with */ handle Repos_Handle; /* handle for calls to repository */ char ContextDB; /* name of database for keeping context */ handle CtxDB_Handle; /* handle for calls to context database */ RMID NextRMID; /* next RMID to be handed out */ RMCB* FirstRMCB; /* pointer to 1st res. mgr. control block */ PCB* FirstPRCB; /* pointer to 1st process control block */ SECB* FirstSECB; /* pointer to 1st session control block */ } TPAnchor; • These system control blocks are implemented as semaphores to make sure that a process can operate on these control data structures without being disturbed by other processes.

34. Central Data Structures of TPOS • Descriptive data about processes, transactions, and resource managers are kept in central control blocks. • There is one system RM that is responsible for and encapsulates each type of control block. Examples • TP monitor is responsible for the resource manager control blocks, the process control blocks, and the session control blocks. • The transaction manager is responsible for the transaction control block, and so on.

35. Accessing the Central Data Structures of TPOS • The following function can be called from any process: PID MyProcid (); /* returns the identifier of the process the call is running in */ /* this is actually a call to the basic OS */ TRID MyTrid (); /* returns the transaction identifier the call is executing within */ RMID MyRMID (); /* returns the RMID of the resource manager that has issued the call */ RMID ClientRMID ();/* returns the RMID of the caller’s client */ • The following function can only be called from system resource managers: PCB MyProc (); /* returns a copy of the central process control block */ /* describing the process the caller is running in */ TransCB MyTrans (); /* returns copy of the central transaction control block */ /* describing the transaction the caller is working for */ RMCB MyRM (); /* returns copy of the central resource manager control block */ /* describing the res. mgr. that issued the call */ RMCB ClientRM (); /* like MyRM, but for the caller’s client */ PCB * MyProcP (); /* returns a pointer to the central process control block */ /* describing the process the caller is running in */ TransCB * MyTransP (); /* returns a pointer to the central TA control block */ /* describing the transaction the caller is working for */ RMCB * MyRMP (); /* returns a pointer to the central resource mgr. control block */ /* describing the res. mgr. that issued the call */ RMCB * ClientRMP (); /* like MyRMP, but for the caller’s client */

36. Accessing the Central Data Structures of TPOS Note: • MyTrans will get a copy of all descriptive data for the current transaction. • MyTransP provides, in addition, linkage information to other relevant control blocks.

37. Protection Domains: A Review (1) • Callees typically want to protect themselves from faults in the caller. They want to encapsulate their data so that only they can access them directly. Such an encapsulated environment is called a protection domain.

38. Protection Domains: A Review (2) • There are two ways to provide protection domains: • Process = protection domain: Each process has its own private address space. Service requests are handled by switching processes; that is, by sending a message to the server process. Note: A domain switch requires a process switch, and it may require copying parameters and results between the processes. Example: UNIX

39. Protection Domains: A Review (3) • Address space = protection domain: Service requests are handle by switching address spaces. The address space protection domain of the callee contains: • Some of the caller’s segments, and • The address space belonging to the callee. Note: It is more efficient than process switch. Example: IBMAS/400, IBM MVS/XA, VAX-VMS.

40. Relationships Described by the TPOS’s Central Data Structures (1)

41. Relationships Described by the TPOS’s Central Data Structures (2) Note: When address spaces are used as protection domains, we need to specify which processes can “domain-switch” to which address spaces (for scheduling & protection reasons)

42. Resource Manager Control Block (1) • We assume a Linked List of control blocks for the instance of each entity type. (We could have as easily declared them as relations.) /*** control block structure for all resource manager (server classes) at the node */ typedef struct ResMgr * RMCBP; /* */ typedef struct ResMgr /* control block for describing the known resource */ { /* managers at that node */ RMNAME rmname; /* global name of the resource manager */ RMID rmid; /* the resource manager short name (identifier */ Boolean RMLocal; /* indicates if the RM available at the local node */ pointer acl; /* pointer to access control list to authorize requests */ /* see explanation in Section 6.4 of the textbook */ Uint priority /* priority of this RM for local access scheduling */ Boolean RMactive; /* indicates if the RM is activated or deactivated */ Boolean RMup; /* status flag says resource manager is up or down */ Boolean UpAfterREDO /* says if the resource can operate normally */ /* after REDO recovery has completed */ Uint QueueLength; /* number of requests waiting for that server class */ RMQUEP waiters; /* pointer to the request queue for that resource mgr. */ RMQUEP end_of_chain; /* points to last waiting request; append happens here */ /* queue information refers to local server class only */ /* Continue in the next slide */

43. Resource Manager Control Block (2) RMTA_CBP RMTA_chain; /* points to the 1st control block describing a */ /* transaction the RM is currently working for */ RMPR_CBP RMPR_chain; /* points to chain of control blocks for the processes */ /* allocated to this resource manager */ RMNO_CBP RMNO_chain; /* points to chain of control blocks for the nodes in the */ /* network where this resource manager is available */ procedure rm_Startup; /* invoked at restart */ procedure rm_Shutdown; /* invoked at system shutdown */ /* more stuff needed by the transaction manager, the log manager, and others */ RMCBP next_RMCB; /* next in the list of RM control blocks */ } RMCB; /* */ • Note: There is no control block for server classes. The relationship between server classes and resource managers is 1:1, so both entity types can be represented by just one type of control block.

44. Process Control Block /** control block structure for all processes in server classes ***/ typedef struct Processes *PCBP; /* */ typedef struct Processes /* control block describing a process in a server class */ { /* and its dynamic association */ PID pid; /* process no. provided by the basic OS */ RMID InstanceOf; /* this is the process’s own server class */ RMID RunsIn; /* server class of the res. mgr. process runs in now */ RMID ClientID; /* RMID of client having invoked RunsIn */ TRID WorksFor; /* Trid of transaction under which process currently runs */ Boolean busy; /* does the process currently service a request ? */ Uint priority; /* priority the process has currently been assigned */ PRTA_CBP TAsToDo; /* pointer to a list of suspended transactions */ PRRM_CBP IMayUse; /* list of res. mgrs. to whose address spaces I may switch */ } PCB;

45. Session Control Block /*** control block for all sessions an RM in that node participates in ***/ typedef struct Sessions *SECBP; /* */ struct Sessions /* control block describing one high-level (TP monitor) session */ { char name [BIG]; /* the session name */ Boolean incoming; /* session polarity (incoming or outgoing) */ PID Initiator; /* ID of process that initiated the binding */ NODEID InitNode; /* node where the initiator resides */ PID OtherEnd /* ID of the bound side of the session */ NODEID BoundNode /* node where the bound process runs */ HANDLE handle; /* session handle given out by the CM */ TRID UsedBy; /* transaction that is currently riding on this session */ char * stuff; /* many other things */ } SECB; /* */ Note: • In practice, it is too expensive to establish and release sessions on a per transaction basis. • Rather, sessions are maintained between processes in different nodes over a longer period of time. • The communication manager must keep track of which transactions are associated with which sessions.

46. Control Block for the m:n Relationship Between RMs and Transactions • Template for a control block containing information about a transaction’s association with a resources manager; anchored at RMTA_chain. • typedef struct rmta * RMTA_CBP; /* */ • typedef struct rmta /* control block describing the association between */ • /* one resource manager and one transaction */ • { • TRID ServicedTA; /* ID of the transaction involved */ • pointer DataINeed; /* points to a data structure the RM may want to maintain */ • /* for keeping state pertaining to its work on that TA */ • RMTA_CBP NextTA; /* points to control block for next transaction of RM */ • } RMTA_CB; • These control blocks are rooted in the RMCB. • The variable DataINeed allows a resource manager to maintain context for a transaction.

47. Resource Manager’s Request Queue /*** template for an entry in the resource manager’s request queue ***/ typedef struct rmq *RMQUEP; /* */ typedef struct rmq /* control block describing one TRPC to that res. manager */ { /* that could not be scheduled immediately for lack of */ /* processes */ pointer RequestMsg; /* pointer to the message contents; depends on the */ /* interface that the request is directed to */ pointer RPC_Data /* points to a control block describing the RPC context */ long timeout /* defines a timeout interval after which the waiting */ /* request is cancelled */ RMID ClientType; /* which resource manager issued the request */ rmInstance ClientInst; /* which instance of the RM issued the request */ RMQUEP NextWaiter; /* pointer to next entry in request queue */ } RMQUE; Note: These queues have to be kept in cases where there are more TRPCs for a RM than the server class has processes.

48. Relationships Between Server Classes & Processes (1) • The first one lists all the processes that may switch to a server class • /*** template for an entry in the resource manager’s process queue ***/ • typedef struct rmpr *RMPR_CBP; /* */ • typedef struct rmpr /* control block describing a process associated with the */ • { /* resource manager */ • PID pid /* process identifier of the associated process */ • Boolean PrimaryProc /* is this a process that was allocated for the resource */ • /* manager’s server class? */ • RMPR_CBP NextProcess; /* pointer to next entry in process list */ • } RMPR_CB /* */ • The second one lists the RMIDs whose code a process is allowed to execute. • /*** template for an entry in the process’ resource manager list ***/ • typedef struct prrm *PRRM_CBP; /* */ • typedef struct prrm /* control block describing a resource manager the */ • { /* process can switch to */ • RMID rmid; /* ID of resource manager implemented by the */ • /* server class */ • char * stuff; /* addressing information, depends on the OS */ • PRRM_CBP NextResMgr; /* pointer to next entry in resource manager list */ • } PRRM_CB 1 2

49. Relationships Between Server Classes & Processes (2) 2 1

50. TARM_CB (RMs used by this transaction) RMPR_CB (processes allocated to this RM) RMTA_CB (transactions currently working for) PRRM_CB (addr. spaces I may switch to) PRTA_CB (suspended transactions) TACB (transactions) RMCB (resource mangers) PRCB (processes) SECB (sessions) RMNO_CB (where this RM is available) Overview of Central Data Structures TPOS_Anchor TPMonCBs TM_CBs SM_CBs LM_CBs IM_CBs TPAnchor FirstRMCB FirstPRCB FirstSECB TMAnchor FirstTACB SMAnchor SMAnchor SMAnchor