Applications and Infrastructure The SQL - PowerPoint PPT Presentation

Loading...

PPT – Applications and Infrastructure The SQL PowerPoint presentation | free to download - id: 9d57d-NTg1M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Applications and Infrastructure The SQL

Description:

Multi-threading Overview. one process per group of terminals ... threads can be assigned to other processors. TP Monitor: Communication Management ... – PowerPoint PPT presentation

Number of Views:34
Avg rating:3.0/5.0
Slides: 26
Provided by: facultyWa9
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Applications and Infrastructure The SQL


1
Applications and InfrastructureThe SQL
2
Agenda
  • HW2 Comments
  • Concluding remarks on Transactions
  • Summary of Last Class
  • Transaction Processing Monitor (continued)
  • Object Request Broker
  • Object Transaction Monitor

3
Summary of Last Class
  • Architects consider the environment in which the
    entity will be placed or used.
  • Software is architected to run in an environment.
  • Other than the OS itself, shared/dynamic link
    libraries are the primary components of current
    desktop runtime environments.
  • Java provides a shared class library plus a
    virtual machine as its environment.
  • EA environments are another matter...

4
Enterprise App. (EA) Environment
  • Historically
  • big companies thin clients (terminals) and fat
    servers
  • depts/small companies fat clients and DBMS
    servers
  • why?
  • as depts/companies grow thin clients and fat
    servers
  • why?
  • Implication EA environment is primarily where?

5
TP Monitor Importance
  • Underlies e-commerce
  • Used for production systems in medium to large
    enterprises -- mission critical
  • Big part of the computer systems market

6
TP Monitor Services
  • Naming map application name to app instance
  • Connection funnels requests from clients to apps
  • Resource Routing request indicates set of
    resources to use, TPM provides access
  • Activation detect and respond to faults by
    creating and/or utilizing redundant parts

7
TP Monitor Bernstein's Model
  • primary function of TPM
  • "control flow of transaction requests between
    terminals or other devices and the application
    program that can process those requests"
  • Message Manager (MM)
  • manages display to and input from terminals
  • Request Control (RC)
  • manages transaction and starts app
  • Application Server (AS)
  • determines app, interfaces with DBMS

8
TP Monitor Control Flow
  • 1.Interact with user to collect input (MM)
  • 2.Translate input into request format (MM)
  • 3.Start transaction (RC)
  • 4.Examine request type to determine app (AS)
  • 5.Execute appropriate app (RC)
  • 6.Commit transaction (RC)
  • 7.Send output to terminal (MM)

9
TP Monitor Message Manager
  • collects input and displays output
  • formats requests for RC (standardizes interface)
  • manages forms (maps requests to terminal's
    format)
  • validates input
  • displays output
  • or, interprets device command (e.g., issue cash)
  • checks security (user id is embedded in each
    request)
  • application developer tasks
  • write forms definitions
  • TPM compiles definitions into requirements
  • write data validation routines

10
TP Monitor Request Control
  • sends request to AS
  • binds request id to AS
  • passes parms from request to app
  • application developer tasks
  • provide mapping of request type to app id
  • dynamic mapping of request type to id
  • helps fault tolerance
  • allows system manager to manually remap to other
    ids for performance
  • can use global name service to allow forwarding
    of requests by AS no need for RC

11
TP Monitor Application Server
  • one or more apps that typically access a shared
    DB
  • TPM
  • links RC to an AS
  • provides app access to terminal
  • may provide process management and communication
    to app as some kind of service

12
TP Monitor Process Management
  • Process
  • address space, processor state and a set of
    resources
  • MMs, RCs, ASs created and managed either as
  • one address space
  • split into multiple address spaces
  • separate processes with more than one thread of
    control
  • What is this splitting approach called?

13
TPM Process Management --Single Address Space
  • one process per terminal
  • all components linked together
  • communication via local procedure calls
  • advantages speed
  • disadvantages
  • doesn't scale well due to OS inefficiencies
  • lengthy process table searches
  • context switching (preserve state and flush
    caches)
  • big consumption of fixed memory
  • possibly too much paging
  • can't control load well
  • not fine-grained enough -- can't prioritize by
    request types

14
TPM Process Management --Multi-threading
Overview
  • one process per group of terminals
  • each terminal has own thread and shares address
    space
  • TPM or OS manages threads
  • Disadvantages
  • weaker storage protection than single address
    space
  • what can mitigate this?
  • two levels of scheduling make priority
    adjustments harder

15
TPM Process Management --Multi-threading
Approaches
  • TPM-managed
  • must subdivide process's memory space
  • must store thread id in service call
  • must handle routing to correct thread after
    service call
  • synchronous call can cause all threads in process
    to block
  • OS-managed
  • knows about threads
  • only thread needing resource will be blocked
  • threads can be assigned to other processors

16
TP Monitor Communication Management
  • message passing
  • establish connection
  • pass message
  • remote procedure call (RPC)
  • call stub that connects to skeleton, marshals
    parameters, sends to skeleton
  • skeleton unmarshals parameters, calls procedure,
    marshals results, sends to stub
  • stub unmarshals results, returns to caller
  • Advantages? Disadvantages?

17
TPM Communication Management -- Message Passing
  • example SNA "conversation"
  • half-duplex (one way at a time)
  • each process can send/recv over the conversation
  • when finished sending, explicitly tells other
    process OK to send

18
RPC vs. LPC
  • LPC -- procedure executes exactly once
  • idempotent
  • executable any number of times without side
    effects
  • RPC semantics
  • exactly once
  • hard to achieve, due to server crashes
  • at most once
  • not at all or one time at most
  • error return means uncertain if procedure
    executed once or not
  • at least once
  • but perhaps more than once typical of idempotent
    procedures

19
Availability
  • fraction of time system is available to do work
  • downtime
  • due to environment, system management, hardware,
    and software failures
  • one hour per day
  • 23 hrs /24 hrs 95.83 of the time system is
    available
  • What is one hour per year availability?
  • When do you recall downtime being reported
    nationally?
  • How to address hw/sw failures? Overloading?

20
TP Monitor Queuing
  • put requests and responses on stable storage
  • each transaction that executes a request dequeues
    request within itself
  • increases reliability -- dequeued request also
    gets rolled back
  • log requests to aid in recovery
  • responses under transaction control guarantees
    delivery
  • requests with multiple transactions
  • can use queue to communicate amongst transactions
  • including scheduling info can help prioritize
  • length of request queues is good measure of
    performance (requests not processed)
  • disadvantage more expensive to enqueue/dequeue
    than to send message directly

21
TP Monitor Configuration/System Management
  • each MM's terminals and forms
  • user authorization information
  • what requests get routed by each RC
  • what programs get managed by each AS
  • name of nodes where each process executes
  • System manager can
  • create/destroy processes
  • move processes between nodes
  • alter sets of forms and programs used by each
    process
  • adjust configuration to improve response time and
    throughput

22
TP Monitor Reporting and Recovery
  • TPM can
  • report transaction rates
  • report response times
  • manage failures automatically due to its
    knowledge of configuration
  • i.e., transparent recovery
  • report on accounting, security and capacity
    planning issues

23
TP Monitor Performance Issues
  • Characteristics
  • 1-100 transaction types per app
  • transaction activity in terms of hardware
    operations varies
  • 0-30 disk accesses, 10K-1M instructions, 2-20
    messages
  • Metrics
  • response time
  • for clients to receive response to a request
  • throughput
  • number of transactions per second

24
Object Request Brokers
  • conceptually
  • communication bus for object access and
    interaction
  • in reality, shared libraries of code used by
  • client objects to access distributed services
  • server objects to provide distributed services
  • client stubs and server skeletons that handle
  • marshaling/unmarshaling
  • method identification and location
  • object activation (server side)
  • foundation for object services

25
Object Transaction Monitor
  • fueled by need to build enterprise apps
  • more rapidly
  • with higher reliability
  • high interoperability
  • better development environments
  • focus on objects, not application procedures
  • separates application services from system
    details
  • ORB TPM using objects
  • also called Component Transaction Monitor(CTM)
About PowerShow.com