Ch 6. Transaction Processing Monitors

1
Ch 6.Transaction Processing Monitors

• Dr. Kien A. Hua

2
Transaction Processing Monitor

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

3
Layering of Services in a Transaction Processing
System (1)

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

4
Layering of Services in a Transaction Processing
System (2)

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

5
Coordination of Resource Managers (1)

• Transaction control must be exercised over all
  resource manager interactions within one
  transaction.
• The following are required for the web of a
  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 a
  living.
• Furthermore, it declares a number of callback
  entries, which can be called when certain events
  happen.
• If the RM maintains any durable objects, it must
  be able to accept rollback and prepare/commit
  callbacks from the TM.
• The RM exports the callback entries to the
  transaction manager when it first checks in with
  the TP monitor.
• The number of callback entries provided by a RM
  depends on its level of sophistication.
• Note This can result in multiple threads
  executing the 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
Installing a New Resource Manager (1)

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

11
Installing a New Resource Manager (2)

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

12
Resource 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 the resource manager exports, the
interfaces it uses from other general resource
managers and the system resource manager
interfaces it has to call to support the
transaction protocol.
13
Resource Manager Sessions
If a client C repeatedly invokes server class S,
how should that be handled? We need to consider
three scenarios.
14
Independent Invocations

• A server class S can be called arbitrarily often,
  and the outcome of each call is independent of
  whether or not the server class has been called
  before.
• Example
• The server reads records from a database.
• It performs some statistical computations on
  them, and returns the result.
• Since the server keeps no state about the call,
  it can declares its consent to the 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

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

18
Implementing State Associated with a
Client-Server Interaction
Context 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 or the server has to do is to
  declare that it need one.
• Typically, the request for a session is issued by
  the server. Applications do not want to be
  bothered with TPOS.
• The price for this is considerable overhead in
  the TPOS for maintaining and recovering sessions.

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

• Context is passed back and forth explicitly
  between client and server upon each request and
  reply.
• This approach relieves the TPOS of the problem of
  context management.

22
Context Management Technique Context Passing (2)

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

23
Context Management Technique Context Passing (3)

• Example Global integrity constraints may depend
  on the result of all previous invocations.

24
Context Management Technique Keep Context in
Database (1)

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

25
Context Management Technique Keep Context in
Database (2)

• Some of the work involved in maintaining the
  context can be off loaded to either an SQL
  database system or to the context management
  service of the TP monitor.

26
Context Management Technique Shared Memory (1)

• All servers of the same class share a segment of
  read/write memory in which invocation context is
  kept.
• Synchronization on the shared memory is done by
  the server.

27
Context Management Technique Shared Memory (2)

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

28
Transaction-Oriented Context (1)

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

29
Transaction-Oriented Context (2)
Note The context needed by S3 is not bound to
any of the previous client-server interactions,
but it is bound to the transaction as such.
30
Transaction-Oriented Context (3)

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

31
Anchor of TPOS (1)

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

32
Anchor of TPOS (2)

• The declaration shows five system resource
  managers. This is a basic set real systems might
  have more.
• Each resource manager has its own local anchor,
  where this 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,
  because the TPOS comes up before any of the RMs
  is activated).

33
Anchors of System Resource Managers

• The anchor of a system resource manager has no
  fixed layout.
• The TP 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 ContextDB / name of database for keeping
  context /
• handle CtxDB_Handle / handle for calls to
  context database /
• RMID NextRMID / next RMID to be handed out /
• RMCB FirstRMCB / pointer to 1st res. mgr.
  control block /
• PCB FirstPRCB / pointer to 1st process control
  block /
• SECB FirstSECB / pointer to 1st session
  control block /
• TPAnchor
• These system control blocks are implemented as
  semaphores to make sure that a process can
  operate on these control data structures without
  being disturbed by other processes.

34
Central Data Structures of TPOS

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

35
Accessing the Central Data Structures of TPOS

• The following function can be called from any
  process
• PID MyProcid () / returns the identifier of the
  process the call is running in /
• / this is actually a call to the basic OS /
• TRID MyTrid () / returns the transaction
  identifier the call is executing within /
• RMID MyRMID () / returns the RMID of the
  resource manager that has issued the call /
• RMID ClientRMID ()/ returns the RMID of the
  callers client /
• The following function can only be called from
  system resource managers
• PCB MyProc () / returns a copy of the central
  process control block /
• / describing the process the caller is running
  in /
• TransCB MyTrans () / returns copy of the
  central transaction control block /
• / describing the transaction the caller is
  working for /
• RMCB MyRM () / returns copy of the central
  resource manager control block /
• / describing the res. mgr. that issued the
  call /
• RMCB ClientRM () / like MyRM, but for the
  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 /

36
Accessing the Central Data Structures of TPOS

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

37
Protection Domains A Review (1)

• Callees typically want to protect themselves from
  faults in the caller. They want to encapsulate
  their data so that only they can access them
  directly. Such an encapsulated environment is
  called a protection domain.

38
Protection Domains A Review (2)

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

39
Protection Domains A Review (3)

• Address space protection domain Service
  requests are handle by switching address spaces.
  The address space protection domain of the callee
  contains
• Some of the 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)
Note When address spaces are used as protection
domains, we need to specify which processes can
domain-switch to which address spaces (for
scheduling protection reasons)