ch 6. transaction processing monitors
DESCRIPTION
Ch 6. Transaction Processing Monitors. by Dr. Hua COP 6730. 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. - PowerPoint PPT PresentationTRANSCRIPT
1
Ch 6.Transaction Processing Monitors
by
Dr. Hua
COP 6730
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, database, 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 same of its data structure 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 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 callback 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
Install A New Resource Manager (1)RMID rmInstall (RMNAME, &rm_callbacks,
AccessComtrolList,
stuff); /*other info. For TP monitor*/
• RMNAME is the user-supplied global external ID.• &rm_callback is an array of pointer 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 TPPC stub of the respective RM’s address space.
11
Install 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 form 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 there source 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 SessionsIf a client C repeatedly invokes server class C, how should that be handle?
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 – A mail server stores the the various parts of a message
in a database.
– It maintains a consistency constraint that says that all mails must have at last 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
1. Context is maintained by a communication session.
2. Context is passed back and forth.
3. The servers write context information to a database.
4. 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 of 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 ManagementIf 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. Note: A BindID uniquely identifies an association between a client instance and a server instance.typedef struct{ /* */
rminstance EndA; /* one end of stateful interaction */rmInstance EndB; /* other one end of stateful interaction */Uint SeqNo; /* sequence no. to distinguish */
/* between multiple stateful interaction *//* among the same servers. */
}BindId; /* handle for a stateful interactions */
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 */
21
Context Mgmt. 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 Mgmt. Technique: Context Passing (2)
• Since re_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 Mgmt. Technique: Context Passing (3)
Example: global integrity constraints may depend on the result of all previous invocations.
24
Context Mgmt. 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 is belongs to.
25
Context Mgmt. 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 Mgmt. 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 Mgmt. 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 system.
28
Transaction-Oriented Context (2)• 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.
29
Transaction-Oriented Context (2)• Transaction-Oriented Context: This type of
context is bound to the SoC established by a transaction rather than to an isolated client-server interaction.
ServerClass
C
ServerClass
S1
ServerClass
S3
ServerClass
S2time T3
time T1 time T2
time T4 (need the context established by the earlier call to S3 from S1
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 type of state information; that is, it must distinguish wheatear a piece of context is identified by the client-server interaction or by the TRID.
– Each server that manages persistent object must be implemented such that it can keep transaction-oriented context.
– The TRPC mechanism must provides means for servers of any type to establish a stateful interaction with a client in case this should be needed (client-orient 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; /* */
• The declaration shows five system resource managers. This is a basic set; real system might have more.
• Each resource manager has its own local anchor, where this RM’s data structures are rooted.
32
Anchor of TPOS (2)Note: Keeping the pointer to the anchors of system
RMs in TPOS_Anchor ensures that addressability can be established in a orderly manner upon system startup. (This is necessary, because the TPOS come up before any of the RMs is activated).
33
Anchors of System Resources 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 ContrextDB; /* name of database for keeeping context */
handle CtxDB_Handle; /* handle for calls to context databse */
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 block, and the session control blocks.
The transaction manager is responsible for the transaction control block, and so on.
35
Accessing The Central Data Structure of TPOS
1. 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 transacition 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 */
2. The following function can only be called from system resource manager:PCB MyProc (); /* returns a copy of the cnetral 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 Structure of TPOS (Cont’d)
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:1. 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)2. Address space = protection domain: Service
requests are handle by switching address spaces. The address space protection domain of the callee contains:
i. Some of the caller’s segments, and
ii. 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)
42
Resource Manager Control Block• We assume a Link List of control block for the instance of each entity type. (We
could have a 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(Cont’d)
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 (see p.96), 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 */HANDLE handle; /* node where the bound process runs */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 (see p.43)
• 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 mq *RMQUEP; /* */
typedef struct mq /* control block describing one TRPC to that res. manager */
{ /* that could not be scheduled immediately for lack of *//* processes */
pinter RequestMsg; /* pointer to the message contents; depends on the */
/* interfact 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 then the server class has processes.
48
Relationships Between Server Classes & Processes
• 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 NextPrcoess; /* 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 rmpr *RMPR_CBP; /**/
typedef struct rmpr /* 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*/
RMPR_CBP NextResMgr; /* pointer to next entry in resource manager list*/
} RMPR_CB
1
2
49
Relationships Between Server Classes & Processes (Cont’d)
1
2
50
Review of Central Data StructuresTPOS_Anchor
TPMonCBs TM_CBs SM_CBs LM_CBs IM_CBs
TPAnchor
FirstRMCB FirstPRCB FirstSECB
TMAnchor
FirstTACB
SMAnchor SMAnchor SMAnchor
secb
(sessions)
PRCB
(processes)
RMCB
(resource mangers)
TACB
(transactions)
PRTA_CB
(suspendedtransactions)
PRRM_CB
(addr. spaces I may switch to)
RMTA_CB
(transactions currently
working for)
RMPR_CB
(processes allocated
to this RM)
RMNO_CB
(where thisRM is available)
TARM_CB
(RMs used by this transaction)
51
• The core data structures are maintained by the TPOS.
• There is one system resource manager that is responsible for and encapsulates each type of control block in the control data structures.
TP Monitor and TPOSTP Monitor
RMs
ProgrammingEnvironment
TPOSTM
TRPC
LOG
SESSION
CENTRALDATA
STRUCTURE
52
Central Data Structure (1)
53
Central Data Structure (2)
54
Applications of Queues (1)1. Load Control: If there is a temporary peak in
the request rate for a RM, the requests can be put into a temporary queue in front of server class (kept in volatile storage).
55
Application of Queues (2)2. End User Control: It is critical for the real actions
at the end points of the system to be in accord with the central RMs.
(such queues must be kept in durable storage).
Teller Machine
Thank you ....
Receipt“dispense
$20”
“subtract$20”
Central RMs
“dispense $20”
56
Application of Queues (3)3. Recoverable Data Entry: The key point here is
not to lose any input data, even if the system crashes before they get processed.
(data queues must be kept in durable storage).
High input rate
Transaction
Data Queue
57
Application of Queues (4)4. Multi-Transaction Requests: The queues
maintain durable information about the association between different RMs.
Client A
Client B
Might be identical
Server1
Server2
Server3
Server4
Output queue of Server 3OR
Input queue of Server 4
58
Queued Transaction Processing (QTP)For each request, there are three transactions:
1. The 1st transaction creates the request and enters it into the server’s input queue.
2. The 2nd transactions processes the request in the server and enters the result into the client’s response queue
3. The 3rd transaction takes the response out of the client’s response queue and presents it to the user (or does whatever is required).
59
Queued Transaction Processing (QTP)(Cont’d)
Example: This is essentially the way IMS/DC structures its work.
60
Request & Response Queues• The QTP model implies durable relationships
between a resource manager and its queues. – Since each request, as well as each response, is
recorded durably in a queue, there is a history of resource manager interactions that makes it possible to determine specifically what happened last between a certain client and its server.
61
Request & Response Queues (Cont’d)
• The behavior of the client with respect to one request is shown in the following state diagram:
The client has to be connected to the queueing system in order to issue requests.
It then can switch back and forth between sending requests to servers and receiving responses from them.
Finally, it can disconnect from the queue only if there are no outstanding responses.
62
Queueing System as a Resource Manager
• Queueing system can best be thought of as a special resource manager that handles request and response queues.
• Registering a client with a queue establishes a recoverable session between the client and the queue RM.
This is another example of the stateful interaction between a client and a server.
• The session is recoverable in that after a crash of either side, it can be resumed with all state information reestablished as of the last successful transaction that updated the queue.
63
Operations on the Queueing Systemtypedef char[BIG] QUNAME;
/* globally unique name for the queue */typedef Uint QUID;
/* locally unique identifier for the queue */typedef TRID RQID;
/* request identifier, based on transaction identifier */typedef char REQUEST[];
/* request are passed as character strings */typedef char RESPONSE[];
/* response are also passed as character string */
Operations:
1. Send: returns TRUE if the request was successfully entered into the queue; FALSE otherwise.Boolean send (REQUEST DoThis,
RQID rqid, /* ID of the request */ QUID ToQueue, /* input queue of the server */ QUID RespQueue); /* output queue of the sever */
64
Operations on the Queueing System(Cont’d)
Operations:
2. receive: receives the next response from the queue specified in RespQueue.
RESPONSE receive (QUID RespQueue,
Response KeepThat);
Some client-specific data passed in KeepThat are stored by the queueing system if the response has been taken from the queue successfully.
3. reReceive: presents the response of the last receive successfully executed by that client. It is used after restart to find out which was the last piece of work it has successfully executed.
RESPONSE reReceive (QUID RespQueue);
65
Opening and Closing a SessionThe state of the session:typedef struct SessionParms *QstatePtr;
struct SessionParms /* parameters describing the state of the session between a client
and the queueing system */
{
QUID quid; /* ID of the queue involved */
RQID LastSend; /* ID of the last request sent
by the client */
RQID LastRcvd; /* ID of the last response
delivered to the client */
RESPONSE response; /* informaiton passed by the
client with the last
successful receive operation
-- thru KeepThat */
} QState;
66
Opening and Closing a Session (Cont’d)
Operations:
1. Connect: If the session had not been closed down explicitly before, the system returns the state of the session (as shown previously). If the session is newly established, Qstate contains NULL entries.
Qstate Connect ( RMID MyRMID,
QUID ToQueue);
2. Disconnect: Client closes the session with the specified queue.
Qstate Disconnect ( RMID MyRMID,
QUID FromQueue);
67
The ticket printer advances a counter that can be read from the client process each time a ticket is printed.
1. The client reads the counter value (e.g. “13”), receives the response from the RespQueue (passing the counter value in the parameter KeepThat).
receive (RespQueue, 13);
2. The client commits, and then prints the ticket.
A Restart Example: A Ticket Printer
Client Server Database
12
13
68
A Restart Example: A Ticket Printer(cont’d)
3. Upon restart, it gets the last value passed in KeepThat as part of the state of the queue.
Connect (MyRMID, RespQueue);case i: LastSent = LastRcvd.
If value (KeepThat) = printer_counter
Then
The response had not been processed before the crash, so printing must be done.
Else
The ticket has already been printed.
case 2: LastSent LastRcvd.
Response processing had been completed before the crash, and a subsequent request had been entered. The response to that request has not yet arrived, so all the client has to do is to enter the request sent state.
69
Load Balancing• How many processes should be given to a server
class?• When a request arrives at a server class, and all
processes are busy handling requests:– Should a new process be created for the server class;
OR– Should the request wait for a process to become
available?
• If the server class is distributed among several nodes, should the request be sent there rather than kept waiting locally. All this boils down to the question of how many virtual
machines of which types should be maintained? And where?
70
Local Process Scheduling• TP monitor knows which server classes it creates
a process for. It also keeps statistics about that server class utilization.
• In most systems, dynamic scheduling relies on table lookups (and therefore is essentially predetermined by the static decision), along with a few rules of thumb.
1. If the service is available in the same address space where the request originates, just keep the process and the address space.
2. If the service is available in the different address space, then current process can bind to, just keep the process.
71
Local Process Scheduling (Cont’d)
3. If the service is not locally available, pick a node where it is and send out the request. Now the request is the node’s problem.
4. If the service is locally available, and there is an idle process providing that service, send the request to that process.
5. If none of the cases holds, and the service is only locally available, decide on the basis of CPU and server class utilization whether or not to create a new process. If the service is also available at other nodes, see if there is a lightly loaded one, which can provide fast response; else queue it.
72
Independencies of Local Server LoadsLoad balancing performed by the TP monitor must
look at both the utilization of each server class and the utilization of the underlying physical resources.
73
THRASHINGIncreasing concurrency
Increasing probability of access conflicts on shared data.
More and more transactions actually wait for other transaction to finish.
Reducing the load on the CPU. Allowing more processes to be created, which further
increases the service time.
This phenomenon, known as thrashing, is caused by making scheduling decisions with insufficient information (e.g., the number of server processes is not considered in load balancing).
74
THRASHING (Cont’d)
75
Scheduling Across Node BoundariesThe scheduling decision has to be based on the following considerations:
Sl: expected local response time based on CPU utilization and server class utilization.
Sr: expected response time at the remote server, given the utilization of its resources.
Tc: communication overhead based on the utilization of the communication medium.
If any remote node can be found such that
Sr + Tc < Sl. Then the request should be expected at that node.
76
Scheduling Across Node Boundaries(Cont’d)
Question: Does the TP monitor have to keep track of the performance figures of remote servers as well as local ones?
Answer: 1. TP monitors supervising parts of the same server class
need to be in session with each other anyway, and one type of message that is exchanged via such sessions is a periodic sample of the utilization, response time, and so on, of the local resources at the participating nodes
2. Performance figures of remote nodes do not have to be kept current to the millisecond; the principle of locality is applicable to load balancing, too, and thus states that load patterns change gradually.
77
Control Block Death• Assume two server classes, A and B. There are N
nodes in the system and each node has Ia processes of A and Ib processes for B.
• According to our scheduling model, each instances of A could send its request to any instance of B.
• If this configuration operates in that model for a while, each instance of A eventually will be in section with each instance of B.The number of control blocks growing quadratically
will get too large.
Note: This is likely to happen in large system.
78
Data Affinity
In current systems, such a load-sensitive data partitioning is often combined with application specific routing; after all, the TP monitor does not understand the parameter fields of the data files.
(heavily loaded) (lightly loaded)
79
Authentication• User authentication: When a user wants to
establish a session with the system (logon, the server authenticates him/her by checking if he/she knows the password
A userid that has been successfully authenticated is called an authorization ID (authid, for short).
• Session authentication: This is similar to user authentication, except that the user is mainly a process running on a different node.
Challenge response: The client and the server share a secrete encryption key.
80
First round: The server challenges the client to decrypt a random number.
Second round: The client can also authenticate the server by challenging it to decrypt a second random number.
Note: This scheme is the basis of IBM’s SNA authentication mechanism
Authentication (Challenge Response)
random number N
Compare
Encrypt
secretekey
SERVER
Decrypt
samesecrete
key
CLIENT
N
encryptednumber EN
decryptednumber DEN
81
1. File access control: O.S.s use a two-dimensional access matrix that specifies which subject is allow to do what on which object.
subject: userid, user group, program, …
object: file, group of file (directory), program, …
what: create, delete, read, write, link, load, and execute.
userA can get to fileF only thru controlled channels.
2. Memory access control: one can get from a lower authority domain to a higher authority domain only through special instructions or O.S. calls
Authorization
objectsubject programP fileF
userA
programP
execute
read/write
82
TP Monitor: Authentication & Authorization
• Can a TP monitor just use the O.S. services to perform authentication and authorization?
Answer: NO!
Reasons:
The units for which the O.S. has access control are large and long-lived: process, sessions, and files
The TP monitor, on the other hand, has to do authorization on a per-request basis (not on a session basis).
83
TP Monitor: Authentication & Authorization (Cont’d)
• The TP monitor, upon each request for service S issued by a user with authid A, has to check whether
this user is allowed to invokethis service (application) fromthis terminal (application) atthis day in the week (time of the day) on this object withthese parameters.
84
The Criteria for Access Control• Classical Time-Sharing Environment:
1. As the user logs on, he/she gets a process ( or a number of them), which runs under his/her authid.
2. Programs that are loaded into this process’s address space execute under the same authid, making it easy to decide on whose behalf a request is issued.
85
The Criteria for Access Control (Cont’d)
• Client-Server Environment:
What should be the criteria for access control under these circumstances?
86
Request-Based Access ControlWhat should be the criteria for access control in a
client-server environment?1. Collect all the authids along the way and specify
access rights for these concatenationsThis is neither manageable nor even required.
2. Request-based access control exercised by the TP monitor is usually based on two-level scheme.
i. The TP monitor checks the client’s authority to call the server, and passes the transaction authid (userid) along with each request.
ii. The RM uses the transaction’s authid to decide whether it can provide the service to the client, given that it works on behalf of that user.
87
Request-Based Access Control (Cont’d)
Note: The TP monitor checks only the client’s authority to call the server; the second part, which uses the transaction authid, is left to the RM.
88
Request-Based Access Control Properties
1. Restrictive: The mail server can access all the tuples in the mail database. However, it must be prevented, of course, from giving a user tuples that do not belong to his/her mail box.
2. Permissive: Assume that I want to use the mail system to send
a file out of my private database to Jim As usual, the mail system calls upon the database,
but mail guy has no access rights on my file. Knowing, though, that its actually myself calling,
these rights can be granted temporarily.
89
Request-Based Access Control Properties (Cont’d)
90
When to do Authorization?• Bind-time authorization: Whenever a user
invokes a RM, the TP monitor do a lookup.Select *
from TP_access_matrix
where
authid = “myself” and
nodeid = “here” and
rmid = :rmid and
entry_name = ‘ServiceEntry’;
91
When to do Authorization? (Cont’d)
Problem: This is too expensive.A solution:
When the TP monitor loads the code for the application into a process’s address space, it has to resolve all the external references
If the application supplies names of the services, the TP monitor can check right away if the application program makes any nonauthorized calls.
• Run-time authorization: Bond- time authorization cannot be used if the access condition contains time constraints or restrictions on locations.
A solution: The TP monitor keeps an in-memory copy of authorized requests in a data structure that provides fast access via authid.
92
When to do Session Authentication?Should a node perform session authentication every
time it receives a service request from a remote node?– A truly paranoid system might do just that
– In normal system: A session is kept between the TPOSs on either
side, they have authenticated each other. If the client TPOS has also authenticated the user,
it can indicate this in the request message, suggesting that the server need no do so again.
93
Restart Processing: (1)1. After a crash, the BOS performs the following:
1.1 The BOS first bootstraps itself back into existence.
The log must come up early with the BOS.
1.2 The BOS performs its restart according to a startup script that bring up the TPOS.
2. The TPOS performs the following:2.1 Format all the system control blocks
needed for managing the RMs.
2.2 Load the description of all local RMs into RMTable, and enter its processes into RMTable.
94
Restart Processing: (2)2.3 Execute the TPOS startup script:
For each active RM, start the prespecified number of processes for that server class and load the code. Update the PRTable.
Call the TM at its rm_Startup entry. It reads the log to determine the active transactions at the time of the crash, as well as the RM involved, and formats the TATable accordingly.
Call the Communications Manager (CM) at its rm_ Startup entry. The TM feeds all relevant log records to the CM in order for it to recover its transactional sessions.
95
Restart Processing: (3)2.4 Bring up all the RMs at that node and orchestrating
their recovery. RMs are brought up according to the sequence
prescribed in the TPOS startup script.
(This is necessary to make sure that services required for the restart of other RMs are in place before they are brought up).
When a RM can be brought up, the TP monitor activates it at the rm_Startup entry point.
The RM then does whatever is needed for its own initialization and eventually calls the Identify function of TM.
96
Restart Processing: (4)2.4 Cont’d
The TM scans the log to see if there is any recovery work to do for that RM. If so,
i. it feeds the REDO records to the RM thru the rm_REDO callback entry.
ii. After that, the same is done for the UNDO records.
The TM returns from the Identify call, and the RM eventually returns from the startup call.
97
Restart Processing: Summery1. BOS bootstraps itself back into existence, bring
up the log.
2. BOS execute the BOS startup script to bring up the TPOS.
3. TPOS executes its startup script to– determine the active transactions at the time of the
crash.
– call the CM to recover the transactional sessions
– bring up all the RMs and orchestrate their recovery.
98
Restart Processing: Summery (Cont’d)