Download Three-Tier Architecture for Transaction Processing: Sessions, Communication, Scalability and more Lecture notes English Language in PDF only on Docsity!
The Architecture of Transaction
Processing Systems
Chapter 23
2
Evolution of Transaction
Processing Systems
• The basic components of a transaction
processing system can be found in single
user systems.
• The evolution of these systems provides a
convenient framework for introducing their
various features.
3
Single-User System
- Presentation Services - displays forms, handles flow of information to/from screen
- Application Services - implements user request, interacts with DBMS
- ACID properties automatic (isolation is trivial) or not required (this is not really an enterprise)
presentation application services services DBMS
user module
centralized system
4
Centralized Multi-User System
• Dumb terminals connected to mainframe
- Application and presentation services on mainframe
• ACID properties required
- Isolation: DBMS sees an interleaved schedule
- Atomicity and durability: system supports a major enterprise
• Transaction abstraction, implemented by
DBMS, provides ACID properties
5
Centralized Multi-User System
user module
central machine
presentation application services services
presentation application services services
communication
DBMS
dumb terminal (^6)
Transaction Processing in a
Distributed System
• Decreased cost of hardware and
communication make it possible to
distribute components of transaction
processing system
- Dumb terminal replaced by computers
• Client/server organization generally used
7
Two-Tiered Model of TPS
DBMS
database server machine
presentation application services services
presentation application services services
client machines
communication 8
Use of Stored Procedures
- Advantages that result from having the database server export a stored procedure interface instead of an SQL interface - Security: procedures can be protected since they are maintained at the enterprise site - Network traffic reduced, response time reduced - Maintenance easier since newer versions don’t have to be distributed to client sites - Authorization can be implemented at the procedure (rather than the statement) level - Procedures can be prepared in advance - Application services sees a higher level of abstraction, doesn’t interact directly with database
9
Three-Tiered Model of TPS
DBMS
database server machine
presentation server
client machines
communication
presentation server
application server
application server machine
10
Application Server
- Sets transaction boundaries
- Acts as a workflow controller : implements user request as a sequence of tasks - e.g., registration = (check prerequisites, add student to course, bill student)
- Acts as a router
- Distributed transactions involve multiple servers
- Server classes are used for load balancing
- Since workflows might be time consuming and application server serves multiple clients, application server is often multi-threaded
11
Transaction Server
• Stored procedures off-loaded to separate
(transaction) servers to reduce load on DBMS
• Transaction server located close to DBMS
- Application server located close to clients
• Transaction server does bulk of data processing.
- Transaction server might exist as a server class
- Application server uses any available transaction server to execute a particular stored procedure; might do load balancing
- Compare to application server which is multi-threaded 12
Three-Tiered Model of TPS
DBMS
database server machine
present. server
client machines
communication
present. server
applic. server
applic. server machines
trans. server
trans. server machines
19
Number of Sessions
• Let n 1 be the number of clients, n 2 the number
of application servers, and n 3 the number of
transaction/db servers
• Sessions, two-tier (worst case) = n 1 *n 3
• Sessions, three-tier (worst case) = n 1 +n 2 *n 3
• Since n1 » n2, three-tiered model scales better
client
application
trans/db (^20)
Sessions in Three-Tiered Model
presentation server
presentation server
presentation server
presentation server
application server
application server
transaction server transaction server
database server
database server
21
Client/Server Sessions
• Server context (describing client) has to be
maintained by server in order to handle a
sequence of client requests:
- What has client bought so far?
- What row was accessed last?
- What is client authorized to do?
22
Client/Server Sessions
- Where is the server context stored?
- At the server - but this does not accommodate:
- Server classes: different server instances (e.g., transaction servers) may participate in a single session
- Large number of clients maintaining long sessions: storage of context is a problem
- In a central database - accessible to all servers in a server class
- At the client - context passed back and forth with each request. - Context handle
23
Queued vs. Direct Transaction
Processing
- Direct : Client waits until request is serviced. Service provided as quickly as possible and result is returned. Client and server are synchronized.
- Queued : Request enqueued and client continues execution. Server dequeues request at a later time and enqueues result. Client dequeues result later. Client and server unsynchronized.
24
Queued Transaction Processing
client (^) server
recoverable request queue
recoverable reply queue
T 1 : enqueue request
T 2 : dequeue request
T 2 : enqueue reply
T 3 : dequeue reply
25
Queued Transaction Processing
• Three transactions on two recoverable queues
• Advantages :
- Client can enter requests even if server is unavailable
- Server can return results even if client is unavailable
- Request will ultimately be served even if T 2 aborts (since queue is transactional) 26
Heterogeneous vs. Homogeneous
TPSs
- Homogeneous systems are composed of HW and SW modules of a single vendor - Modules communicate through proprietary (often unpublished) interfaces - Hence, other vendor products cannot be included - Referred to as TP-Lite systems
- Heterogeneous systems are composed of HW and SW modules of different vendors - Modules communicate through standard, published interfaces - Referred to as TP-Heavy systems
27
Heterogeneous Systems
- Evolved from:
- Need to integrate legacy modules produced by different vendors
- Need to take advantage of products of many vendors
- Middleware is the software that integrates the components of a heterogeneous system and provides utility services - For example, supports communication (TCP/IP), security (Kerberos), global ACID properties, translation (JDBC)
28
Transaction Manager
• Middleware to support global atomicity of
distributed transactions
- Application invokes manager when transaction is initiated
- Manager is informed each time a new server joins the transaction
- Application invokes manager when transaction completes
- Manager coordinates atomic commit protocol among servers to ensure global atomicity
29
Transaction Manager
(Two-Tiered Model)
DBMS
database server machines (local ACID properties)
present. applic. services services
- • • client machines
- • •
- • •
DBMS
Transaction manager
begin / commit
service invocations
atomic commit protocol
30
TP Monitor
- A TP Monitor is a collection of middleware components that is useful in building hetereogeneous transaction processing systems - Includes transaction manager - Application independent services not usually provided by an operating system
- Layer of software between operating system and application
- Produces the abstraction of a (global) transaction
37
Remote Procedure Call
• Asymmetric : caller invokes, callee
responds
• Synchronous : caller waits for callee
• Location transparent : caller cannot tell
whether
- Callee is local or remote
- Callee has moved from one site to another
38
RPC Implementation: Stubs
client code
call p(…);
server code p: •
client stub p: •
send msg
server stub
receive msg;
call p(…);
distributed message passing kernel
distributed message passing kernel Site A Site B
39
Stub Functions
• Client stub :
- Locates server - sends globally unique name (character string) provided by application to directory services
- Sets up connection to server
- Marshalls arguments and procedure name
- Sends invocation message (uses message passing)
• Server stub :
- Unmarshalls arguments
- Invokes procedure locally
- Returns results 40
Connection Set-Up: IDL
- Server publishes its interface as a file written in Interface Definition Language (IDL). Specifies procedure names, arguments, etc
- IDL compiler produces header file and server- specific stubs
- Header file compiled with application code (type checking possible)
- Client stub linked to application
41
Connection Set-Up: Directory
Services
- Interface does not specify the location of server that supports it. - Server might move - Interface might be supported by server class
- Directory (Name) Services provides run-time rendezvous. - Server registers its globally unique name, net address, interfaces it supports, protocols it uses, etc. - Client stub sends server name or interface identity - Directory service responds with address, protocol 42
RPC: Failures
- Component failures (communication lines, computers) are expected
- Service can often be provided despite failures
- Example : no response to invocation message
- Possible reasons: communication slow, message lost, server crashed, server slow
- Possible actions: resend message, contact different server, abort client, continue to wait
- Problem : different actions appropriate to different failures
43
Transactional RPC and Global
Atomicity
- Client executes tx_begin to initiate transaction
- Client stub calls transaction manager (TM)
- TM returns transaction id ( tid )
- Transactional RPC (TRPC):
- Client stub appends tid to each call to server
- Server stub informs TM when it is called for first time
- Server has joined the client’s transaction.
- Client commits by executing tx_commit
- Client stub calls TM
- TM coordinates atomic commit protocol among servers to ensure global atomicity 44
Transaction Manager and TRPC
Application tx_begin invoke TM return
call p(..) pass tid with request return Body Stub
Transaction Mgr, TM generate tid return tid record new subtransaction of tid return
xa_reg (tid) call p(..) p: …. return return Stub Body Resource Mgr, S
service interface
xa interface
tx interface
45
Transaction Manager and Atomic
Commit Protocol
Application
tx_begin invoke TM return
tx_commit invoke TM(tid) return
Body Stub
Transaction Mgr, TM generate tid return tid execute commit protocol return
participate in commit protocol
Stub Body Resource Mgr, S
xa interface
tx interface
46
TRPC and Failure
- Stubs must guarantee exactly once semantics in handling failures. Either: - called procedure executed exactly once and transaction can continue, or - called procedure does not execute and transaction aborts
- Suppose called procedure makes a (nested) call to another server and then crashes. - Orphan is left in system when transaction aborted - Orphan elimination algorithm required
47
Peer-To-Peer Communication
• Symmetri c: Once a connection is established
communicants are equal (peers) - both can
execute send/receive. If requestor is part of a
transaction, requestee joins the transaction
• Asynchronous : Sender continues executing
after send; arbitrary patterns (streams) of
messages possible; communication more
flexible, complex, and error prone than RPC
• Not location transparent
48
Peer-To-Peer Communication
• Connection can be half duplex (only one
peer is in send mode at a time) or full
duplex (both can send simultaneously)
• Communication is stateful : each peer can
maintain context over duration of exchange.
- Each message received can be interpreted with respect to that context
55
Example
• M1 controls flow of chemicals into furnace
• M2 monitors temperature
• M1 must be informed when temperature
reaches limit
• Solution 1 : M1 polls M2 periodically to check
temperature
- Wasteful if limit rarely reached, very wasteful if M1 must respond fast (polling must be frequent)
• Solution 2 : M2 interrupts M1 when limit
reached 56
Event Communication
• Event handling module registers address of its
event handling routine with TP monitor using
event API
- Handler operates as an interrupt routine
• Event generating module recognizes event and
notifies event handling module using event API
• TP monitor interrupts event handling module
and causes it to execute handling routine
57
Event Communication
- If event generating module recognizes event in the context of a transaction, T, execution of handler is part of T
- Problem : event generating module must know the identity of event handling module
event generating module
event handling module, EHM addr:
callback
Notify(EHM)
Register(addr)
58
Event Broker
• Solution : Use broker as an intermediary:
- Events are named ( E )
- Event handling module registers handler with the TP monitor and subscribes to E by calling the broker with E as a parameter
- Event generating module posts E to the broker when it occurs.
- Broker notifies event handler
- If recognition of E in generating module is part of a transaction, execution of handler is also
59
Event Broker
- Broker can cause alternate actions in addition to notifying handler
event handling module, EHM
event generating module
server queue
broker
invoke enqueue
post(E) subscribe(E) register(addr)
addr:
notify(EHM)
60
Storage Architecture
• Much of this chapter deals with various
architectures for increasing performance
• One performance bottleneck we have not
yet discussed is disk I/
• It is hard to get throughput of thousands of
transactions per second when each disk
access requires a time measured in
thousandths of a second
61
Disk Cache
- The DBMS maintains a disk cache in main memory - Recently accessed disk pages are kept in the cache and if at some later time a transaction accesses that page, it can access the cached version - Many designers try to obtain over 90% hit rate in the cache - Many cache sizes are in the tens of gigabytes - We discuss caches in detail in Chapter 9
62
RAID Systems
• A RAID (Redundant Array of Independent
Disks) consists of a set of disks configured
to look like a single disk with increased
throughput and reliability
- Increased throughput is obtained by striping or partitioning each file over a number of disks, thus decreasing the time to access that file
- Increased reliability is obtained by storing the data redundantly, for example using parity bits
63
RAID Systems (continued)
- We discuss RAID systems in detail in Chapter 9
- Here we point out that a number of RAID levels have been defined, depending on the type of striping and redundancy used
- The levels usually recommended for transaction processing systems are - Level 5: Block-level striping of both data and parity - Level 10: A striped array of mirrored disks
64
NAS and SAN
• In a NAS (Network Attached Storage) a file
server, sometimes called an appliance, is
directly connected to the same network as
the application server and other servers
- The files on the appliance can be shared by all the servers
65
NAS and SAN (continued)
• In a SAN (Storage Attached Network) a
server connects to its storage devices over a
separate high speed network
- The network operates at about the same speed as the bus on which a disk might connected to the server
- The server accesses the storage devices using the same commands and at the same speed as if it were connected on a bus
66
NAS and SAN (continued)
• Both NAS and SAN can scale to more
storage devices than if those devices were
connected directly to the server
• SANs are usually considered preferable for
high performance transaction processing
systems because the DBMS can access the
storage devices directly instead of having to
go through a server.
73
Architectures for Transaction
Processing on the Internet
- Browser plays the role of presentation server and application server - Java applet on browser implements the transaction and accesses database using JDBC
- Browser plays the role of presentation server, and servlet program on server plays the role of application server - Servlet program implements the transaction and accesses database using JDBC 74
Architectures for Transaction
Processing on the Internet
- Many high throughput applications require a three- or four- tiered architecture - After getting inputs from browser, the servlet program initiates the transaction on the application server, which is not connected to the Internet - Application server might be separated from the Web server by a firewall - From the TP system’s viewpoint, the browser and servlet program together are acting as the presentation server
75
Architecture of a Web
Transaction Processing System
Web Server (^) Application Server Database Server
Interacts with client Executes the application Hosts the database
The application might be a transaction program that implements the business rules of the Web service
Java servlet receives messages and calls program on application server 76
Web Server
• HTTP Interface to Web
- Java servlet on Web server interacts with client ’s browser using HTTP messages and then initiates programs on the application server
77
Web Application Server
• A Web application server is a set of tools
and modules for building and executing
transaction processing systems for the Web
- Including the application server tier of the system
• Name is confusing because application
server is the name usually given to the
middle tier in an transaction processing
system
78
Web Application Servers
(continued)
• Most Web application servers support the
J2EE (Java 2 Enterprise Edition) standards
• We discuss J2EE
- J2EE One language, many platforms
- A standard implemented by many vendors
- .NET One platform, many languages
- A set of products of Microsoft
79
J2EE
• J2EE defines a set of services and classes
particularly oriented toward transaction-
oriented Web services
- Java servlets
- Enterprise Java beans
80
Enterprise Java Beans
- Java classes that implement the business methods of an enterprise
- Execute within an infrastructure of services provided by the Web application server - Supports transactions, persistence, concurrency, authorization, etc. - Implements declarative transaction semantics - The bean programmer can just declare that a particular method is to be a transaction and does not have to specify the begin and commit commands - Bean programmer can focus on business methods of the enterprise rather on details of system implementation
81
Entity Beans
• An entity bean represents a persistent
business object whose state is stored in the
database
- Each entity bean corresponds to a database table
- Each instance of that bean corresponds to a row in that table.
82
Example of an Entity Bean
- An entity bean called Account, which corresponds to a database table Account - Each instance of that bean corresponds to a row in that table
- Account has fields that include AccountId and Balance
- AccountId is the primary key
- Every entity bean has a FindByPrimaryKey method that can be used to find the bean based on its primary key
- Account has other methods that might include Deposit and Withdraw
83
Persistence of Entity Beans
- Any changes to the bean are persistent in that those changes are propagated to the corresponding database items
- This persistence can be managed either manually by the bean itself using standard JDBC statements or automatically by the system (as described later)
- The system can also automatically manage the authorization and transactional properties of the bean (as described later) 84
Session Bean
• A session bean represents a client
performing interactions within a session
using the business methods of the enterprise
- A session is a sequence of interactions by a user to accomplish some objective. For example, a session might include selecting items from a catalog and then purchasing them.
• The session bean retains its state during all
the interactions of the session
- Stateless session beans also exist
91
Structure of an Enterprise Bean
(continued)
- A deployment descriptor
- Declarative metadata for the bean
- Describes persistence, transactional, and authorization properties
92
Example of Deployment
Descriptor
- The deployment descriptor for a banking application might say that - The Withdraw method of an Account entity bean - Is to be executed as a transaction - Can be executed either by the account owner or by a teller - The Balance field of the Account Bean - Has its persistence managed by the system - Any changes are automatically propagated to the DB
- Deployment descriptors are written in XML
93
Portion of a Deployment
Descriptor Describing
Authorization
<method-permission> <role-name> teller </role-name> <ejb-name> Account </ejb-name> <method-name> Withdraw </method-name> </method-permission>
94
EJB Container
• Enterprise beans together with their
deployment descriptors are encapsulated
within an EJB container supplied by the
Web application server
• The EJB container provides system-level
support for the beans based on information
in their deployment descriptors
95
EJB Container (continued)
- The EJB container provides this support by intervening before and after each bean method is called and performing whatever actions are necessary - When a method is called, the call goes to the similarly named interface method - The interface method performs whatever actions are necessary before and after calling the bean method 96
EJB Container (continued)
- For example, if the deployment descriptor says the method is to run as a transaction - The interface method starts the transaction before calling the method - Commits the transaction when the method completes
- The EJB container supplies the code for the interface methods.
97
Clientclient^ Shopping Cart
Shopping Cart Bean
Order Bean
Local Order
Database
Container
Remote Interface
Session Bean Local Interface
Entity Bean
Remote and Local Interfaces Within a Container
Checkout
98
Persistence of Entity Beans
• Persistence of entity beans can be managed
- Manually by the bean itself (bean-managed persistence) using standard JDBC statements
- Automatically by the container (container- managed persistence, cmp)
99
Example of Deployment
Descriptor for Container Managed
Persistence
<persistence-type> container </persistence-type> <cmp-field> <field-name> balance </field-name> </cmp-field>
100
Get and Set Methods
- The entity bean must contain declarations for get and set methods. For example public abstract float getBalance( ) public abstract void setBalance (float balance)
- The container generates code for these methods
- A client of the bean, for example a session bean, can use - a finder method, for example, FindByPrimaryKey() , to find an entity bean and then - a get or set method to read or update specific fields of that bean.
101
EJB QL Language
- The container will generate the code for the FindByPrimaryKey() method
- The container will also generate code for other finder methods described in the deployment descriptor - These methods are described in the deployment descriptor using the EJB QL (EJB Query Language ) - EJB QL is used to find one or more entity beans based on criteria other than their primary key
102
Example of EJB QL
<query-method> <method-name>FindByName </method-name> <method-params> <method-param>string</method-param> </method-params> </query-method> <ejb-ql> SELECT OBJECT (A) FROM Account A WHERE A.Name =? </ejb-ql>
109
Transactions (continued)
- In container-managed transactions, the deployment descriptor must specify the transaction attributes of each method
- Attributes supported are
- Required
- RequiresNew
- Mandatory
- NotSupported
- Supports
- Never
- The semantics of these attributes are discussed in Chapter 22 110
Restrictions on Attributes
- For message-driven beans, only the Required and NotSupported attributes are allowed - If the bean has the Required attribute and aborts, the message is put back on the queue and the transaction will be called again
- For stateless session beans only Requires, RequiresNew, Supports, Never , and NotSupported are allowed
- For entity beans with container-managed persistence, only Requires, RequiresNew , and Mandatory are allowed.
111
Example of Deployment
Descriptor
<container-transaction> <ejb-name> ShoppingCart <method-name> Checkout </method-name> <trans-attribute> Required </trans-attribute> </container-transaction>
112
Two-Phase Commit
• The container also contains a transaction
manager, which will manage a two-phase
commit procedure, for both container-
managed and bean-managed transactions.
113
Concurrency of Entity Beans
- A number of concurrently executing clients might request access to the same entity bean and hence the same row of a database table
- If that bean has been declared transactional, the concurrency is controlled by the container - If not, each client gets its own copy of the entity bean and the concurrency is controlled by the DBMS - For session beans and message-driven beans with bean- managed concurrency the bean programmer can specify the isolation level within the code for the bean
- The default J2EE implementation of container-managed concurrency is that each client gets its own copy of the entity bean and the underlying DBMS manages the concurrency (^114)
Another Implementation of
Container-Managed Concurrency
- Some vendors of Web application servers offer other alternatives, such as optimistic concurrency control - DBMS executes at READ COMMITTED - All writes are kept in the entity bean until the transaction requests to commit - The intentions list - The validation check verifies that no entity the transaction read has been updated since the read took place. - Not the same validation check performed by the optimistic control discussed earlier - In that control, the validation check verifies that no entity the transaction read has been updated anywhere in its read phase - Both implementation provide serializability
115
Reusability of Enterprise Beans
- Part of the vision underlying enterprise beans is that they would be reusable components - Sam’s Software Company sells a set of beans for shopping cart applications, including a ShoppingCartBean session bean - Joe’s Hardware Store buys the beans - Instead of using the standard ShoppingCartBean, Joe’s system uses a child of that bean, JoesShoppingCartBean that had been changed slightly to reflect Joe’s business rules - Joe also changes the deployment descriptor a bit 116
Reusability of Enterprise Beans
continued
- The implementation of Joe’s system is considerably simplified
- Joe’s programmers need be concerned mainly with Joe’s business rules not with implementation details
- Joe’s shopping cart application will run on any system using any Web application server that supports J2EE - Provided it does not use any proprietary extensions to J2EE
