Ch 6.Transaction Processing Monitors.ppt

《Ch 6.Transaction Processing Monitors.ppt》由会员分享，可在线阅读，更多相关《Ch 6.Transaction Processing Monitors.ppt（41页珍藏版）》请在麦多课文档分享上搜索。

1、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 Servi

2、ces 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.

3、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 environ

4、ment, load control, resource managers, databases, etc. The application typically uses the TRAPS and TPOS, depending on the applications sophistication.Note: These layers do not reflect a strict implementation hierarchy. Rather, it describes a separation of concerns among different system components

5、(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 transactions calls to hang together: Control of

6、 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-rel

7、ated 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

8、 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,

9、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 ent

10、ries provided by a RM depends on its level of sophistication. Note: This can result in multiple threads executing the RMs 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 t

11、he 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 rollba

12、ck */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 ( passes t

13、he address of the resource */* managers recent checkpoint record */,10,Installing a New Resource Manager (1),RMID rmInstall (RMNAME, /*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

14、specified as relative addresses in the load module for that RM. The TP monitor keeps this array in the TRPC stub of the respective RMs address space.,11,Installing a New Resource Manager (2),RMID rmInstall (RMNAME, /*other info. for TP monitor*/AccessControlList allows the TP monitor to check whethe

15、r 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 Managers Interfac

16、es,Fig 6.2: Overview of a resource managers 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

17、 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

18、 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 sta

19、te about the call, it can declares its consent to the transactions 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 curs

20、or. 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

21、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.T

22、here 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 in

23、formation 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 mana

24、ged 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

25、,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; /* oth

26、er 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 serv

27、er 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 *

28、/* 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 app

29、roach 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)

30、, 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 o

31、f 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

32、 of the invocationin 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

33、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

34、 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 i

35、nteraction 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,Transaction-Oriented Context (2),Note: The co

36、ntext 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 pie

37、ce 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 clie

38、nt 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, f

39、rom 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. */ C

40、MAnchorP 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; r

41、eal systems might have more. Each resource manager has its own local anchor, where this RMs 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, b

42、ecause 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 monitors anchor might have the following structure:typedef struct tpa * TPAnchorP; typedef struct tpa /* TP monitor anchor for its

43、control blocks */ char *MyVersion; /* version of the TP monitor running */ char Repository64; /* 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 cont

44、ext 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 a

45、s 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 i

46、s 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

47、 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 *

48、/ RMID MyRMID (); /* returns the RMID of the resource manager that has issued the call */ RMID ClientRMID ();/* returns the RMID of the callers client */ The following function can only be called from system resource managers: PCB MyProc (); /* returns a copy of the central process control block */*

49、 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 i

50、ssued the call */ RMCB ClientRM (); /* like MyRM, but for the callers 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 callers client */,