Ch%206.%20Transaction%20Processing%20Monitors

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
  transactions 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 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
  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 /

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 RMs 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 Managers Interfaces
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 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 Sessions
If 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 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 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
Context information about multiple invocations of
the same server class can be maintained in four
different ways

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.

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 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.
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.

Server Class S1
time T1
time T2
Server Class C
Server Class S3
Server Class S2
time T3
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 RMs 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 monitors 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 Repository64 / 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

• 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
  callers client /
• 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
  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 /

36
Accessing The Central Data Structure of TPOS
(Contd)

• 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 callers 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 TPOSs Central
Data Structures (1)
41
Relationships Described by the TPOSs 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. /

43
Resource Manager Control Block(Contd)

• 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 11 (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 processs 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 mn Relationship Between
RMs and Transactions

• Template for a control block containing
  information about a transactions 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 Managers Request Queue

• / template for an entry in the
  resource managers 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
  managers 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 /
• / managers 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 /

1
2
49
Relationships Between Server Classes Processes
(Contd)
1
2
50
Review of Central Data Structures
TPOS_Anchor
TPMonCBs
TM_CBs
SM_CBs
LM_CBs
IM_CBs
TPAnchor FirstRMCB FirstPRCB FirstSECB
TMAnchor FirstTACB
SMAnchor
SMAnchor
SMAnchor
51
TP Monitor and TPOS
TP Monitor

• 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.

Programming Environment
TPOS
SESSION
RMs
TM
CENTRAL DATA STRUCTURE
TRPC
LOG
52
Central Data Structure (1)
53
Central Data Structure (2)
54
Applications of Queues (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)

• 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).

Central RMs
Teller Machine
dispense 20
subtract 20
Thank you ....
dispense 20
Receipt
56
Application of Queues (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)

• Multi-Transaction Requests The queues maintain
  durable information about the association between
  different RMs.

Server 1
Server 2
Client A
Might be identical
Server 3
Server 4
Client B
Output queue of Server 3 OR Input queue of Server
4
58
Queued Transaction Processing (QTP)

• For each request, there are three transactions
• The 1st transaction creates the request and
  enters it into the servers input queue.
• The 2nd transactions processes the request in the
  server and enters the result into the clients
  response queue
• The 3rd transaction takes the response out of the
  clients response queue and presents it to the
  user (or does whatever is required).

59
Queued Transaction Processing (QTP)(Contd)

• 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 (Contd)

• 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 System

• typedef charBIG 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
• 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(Contd)

• Operations
• 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.
• 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 Session

• The 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 (Contd)

• Operations
• 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)
• Disconnect Client closes the session with the
  specified queue.
• Qstate Disconnect ( RMID MyRMID,
• QUID FromQueue)

67
A Restart Example A Ticket Printer

• The ticket printer advances a counter that can be
  read from the client process each time a ticket
  is printed.
• 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)
• The client commits, and then prints the ticket.

12

Database
Client
Server
13

68
A Restart Example A Ticket Printer(contd)

• 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.
• If the service is available in the same address
  space where the request originates, just keep the
  process and the address space.
• If the service is available in the different
  address space, then current process can bind to,
  just keep the process.

71
Local Process Scheduling (Contd)

1. If the service is not locally available, pick a
   node where it is and send out the request. Now
   the request is the nodes problem.
2. If the service is locally available, and there is
   an idle process providing that service, send the
   request to that process.
3. 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 Loads

• Load 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
THRASHING

• Increasing 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 (Contd)
75
Scheduling Across Node Boundaries

• The 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 lt Sl. Then the request should be expected
  at that node.

76
Scheduling Across Node Boundaries(Contd)

• Question Does the TP monitor have to keep track
  of the performance figures of remote servers as
  well as local ones?
• Answer
• 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
• 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.

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
Authentication (Challenge Response)

• 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 IBMs SNA
  authentication mechanism

SERVER
CLIENT
encrypted number EN
same secrete key
random number N
Encrypt
Decrypt
secrete key
decrypted number DEN
N
Compare
81
Authorization

• 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.
• Memory access control one can get from a lower
  authority domain to a higher authority domain
  only through special instructions or O.S. calls

object
subject
programP
fileF
userA
execute
programP
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
(Contd)

• 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 invoke
• this service (application) from
• this terminal (application) at
• this day in the week (time of the day) on
• this object with
• these parameters.

84
The Criteria for Access Control

• Classical Time-Sharing Environment
• As the user logs on, he/she gets a process ( or a
  number of them), which runs under his/her authid.
• Programs that are loaded into this processs
  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 (Contd)

• Client-Server Environment
• What should be the criteria for access control
  under these circumstances?

86
Request-Based Access Control

• What should be the criteria for access control in
  a client-server environment?
• Collect all the authids along the way and specify
  access rights for these concatenations
• This is neither manageable nor even required.
• Request-based access control exercised by the TP
  monitor is usually based on two-level scheme.
• The TP monitor checks the clients authority to
  call the server, and passes the transaction
  authid (userid) along with each request.
• The RM uses the transactions 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 (Contd)

• Note The TP monitor checks only the clients
  authority to call the server the second part,
  which uses the transaction authid, is left to the
  RM.

88
Request-Based Access Control Properties

• 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.
• 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 (Contd)
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? (Contd)

• Problem This is too expensive.
• A solution
• When the TP monitor loads the code for the
  application into a processs 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)

• 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.
• 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 Contd
• The TM scans the log to see if there is any
  recovery work to do for that RM. If so,
• it feeds the REDO records to the RM thru the
  rm_REDO callback entry.
• 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 Summery

• BOS bootstraps itself back into existence, bring
  up the log.
• BOS execute the BOS startup script to bring up
  the TPOS.
• 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 (Contd)