UNIT IV – CLIENT SERVER TRANSACTION PROCESSING

INTRODUCTION

 ACID properties. ACID is an acronym for atomicity, consistency, isolation, and

durability.

 Flat transactions represent the simplest type of transaction, and for almost all
existing systems, it is the only one that is supported at the application
programming level. A flat transaction is the basic building block for organizing an
application into atomic actions.

 A nested transaction is used to provide a transactional guarantee for a subset of

operations performed within the scope of a larger transaction. Doing this allows
you to commit and abort the subset of operations independently of the larger
transaction.

 TP(Transaction Processing) Monitors specialize in managing transactions from

their point of origin-typically on the client-across one or more servers and then
back to the originating client. When a transaction ends, the TP monitor ensures
that all the systems involved in the transaction are left in a consistent state.
 TP Monitors provide an OS-on top of the existing OS’s that connects in real time
these 1000 of impatient humans with a pool of shared server’s processes-this is
called funneling.
 Conventional and RPC transactions usually involve a human user that requires
immediate attention; they run in high-priority mode. Publish-and-Subscribe
transaction runs as high priority messages too. Batch transactions run in low
priority mode. MOM -based Queued transaction can be of either type.
 TP-Lite is simply the integration of TP Monitor functions in the database engines.
TP-Heavy is TP Monitors which supports the Client/Server architecture and
allow PC to initiate some very complex multi server transaction from the desktop.

1
 CONTENTS
ACID properties

When a transaction processing system creates a transaction, it will ensure that the
transaction will have certain characteristics. The developers of the components that
comprise the transaction are assured that these characteristics are in place. They do not
need to manage these characteristics themselves. These characteristics are known as the
ACID properties. ACID is an acronym for atomicity, consistency, isolation, and
durability.

1. Atomicity

The atomicity property identifies that the transaction is atomic. An atomic transaction is
either fully completed, or is not begun at all. Any updates that a transaction might affect
on a system are completed in their entirety. If for any reason an error occurs and the
transaction is unable to complete all of its steps, the then system is returned to the state it
was in before the transaction was started. An example of an atomic transaction is an
account transfer transaction. The money is removed from account A then placed into
account B. If the system fails after removing the money from account A, then the
transaction processing system will put the money back into account A, thus returning the
system to its original state. This is known as a rollback, as we said at the beginning of this
chapter..

2. Consistency

A transaction enforces consistency in the system state by ensuring that at the end of any
transaction the system is in a valid state. If the transaction completes successfully, then all
changes to the system will have been properly made, and the system will be in a valid
state. If any error occurs in a transaction, then any changes already made will be
automatically rolled back. This will return the system to its state before the transaction
was started. Since the system was in a consistent state when the transaction was started, it
will once again be in a consistent state.

2
Looking again at the account transfer system, the system is consistent if the total of all
accounts is constant. If an error occurs and the money is removed from account A and not
added to account B, then the total in all accounts would have changed. The system would
no longer be consistent. By rolling back the removal from account A, the total will again
be what it should be, and the system back in a consistent state.

3. Isolation

When a transaction runs in isolation, it appears to be the only action that the system is
carrying out at one time. If there are two transactions that are both performing the same
function and are running at the same time, transaction isolation will ensure that each
transaction thinks it has exclusive use of the system. This is important in that as the
transaction is being executed, the state of the system may not be consistent. The
transaction ensures that the system remains consistent after the transaction ends, but
during an individual transaction, this may not be the case. If a transaction was not
running in isolation, it could access data from the system that may not be consistent. By
providing transaction isolation, this is prevented from happening.

4. Durability

A transaction is durable in that once it has been successfully completed, all of the changes
it made to the system are permanent. There are safeguards that will prevent the loss of
information, even in the case of system failure. By logging the steps that the transaction
performs, the state of the system can be recreated even if the hardware itself has failed.
The concept of durability allows the developer to know that a completed transaction is a
permanent part of the system, regardless of what happens to the system later on.

Transaction Models

This topic describes the relationship between the transaction programming models. The
models are:

 Flat Transaction

3
  Distributed Flat Transaction

 Nested Transaction

(i) Flat Transaction

Flat transactions represent the simplest type of transaction, and for almost all existing
systems, it is the only one that is supported at the application programming level. A flat
transaction is the basic building block for organizing an application into atomic actions. It
can contain an arbitrary number of simple actions: these actions may, in turn, be either
protected, real, or even unprotected, if necessary. Putting a flat transaction as an
execution unit around a sequence of either protected or real actions makes the whole
appear as indivisible as far as the application is concerned. These transactions are called
flat because there is only one layer of control by the application. The transaction starts
with begin_transaction and ends with commit_transaction ot abort_transaction. Its an all
or nothing preposition there’s no way to commit or abort parts of a flat transaction.

The major restriction of flat transactions is that there is no way of either committing or
aborting parts of such transactions, or committing results in several steps, and so forth.
Consistency is a necessary characteristic of any computer application and at least partly
depends on the program design and code. Reusability, reentrancy, and quasi-reentrancy

4
are variously used to guarantee that the same code is executed in every invocation of a
transaction. Data store managers should ensure that the order of record insertions does
not influence their effect on the data store; the insertion of record A followed by the
insertion of record B should have the same effect as the insertion of record B followed by
the insertion of record A. Durability of transactions requires a data store forward recovery
facility. This must run independently of the transaction processing system and while the
data being recovered is offline from the transaction processing system.

Back-to-Back Transaction

Limitations of Flat Transaction

 Compound business transactions that need to be partially rolled back

 Business transactions with humans in the loop

 Business transactions that span long periods of time

 Business transactions with a lot of bulk

 Business transactions that span across companies or the Internet

(ii) Distributed Flat Transaction

The transaction must travel across multiple sites to get to the resources it needs. Each
site’s TP monitor must manage its local piece of the transaction. Within a site, the
TP monitor coordinates the transactions with the local ACID subsystem and
resource managers- including database managers, queue managers, persistent
objects and message transports. This is all done using Two-phas commit protocol,
which coordinates the transaction’s commit or abort across multiple sites.

Two Phase Commit Protocol

5
Phase 1
1. The coordinator sends a canCommit? request to each of the participants in the
transaction.
2. When a participant receives a canCommit? request it replies with its vote (Yes or No)
to the coordinator. Before voting Yes, it prepares to commit by saving objects in
permanent storage. If the vote is No the participant aborts immediately.
Phase 2
3. The coordinator collects the votes (including its own).
(a)If there are no failures and all the votes are Yes the coordinator decides to commit the
transaction and sends a doCommit request to each of the participants.
(b)Otherwise the coordinator decides to abort the transaction and sends doAbort requests
to all participants that voted Yes.
4. Participants that voted Yes are waiting for a doCommit or doAbort request from the
coordinator. When a participant receives one of these messages it acts accordingly and in
the case of commit, makes a haveCommitted call as confirmation to the coordinator.

Operations for two-phase commit protocol

canCommit?(trans)→ Yes / No
Call from coordinator to participant to ask whether it can commit a transaction.
Participant replies with its vote.
doCommit(trans)
Call from coordinator to participant to tell participant to commit its part of a transaction.
doAbort(trans)
Call from coordinator to participant to tell participant to abort its part of a transaction.
haveCommitted(trans, participant)
Call from participant to coordinator to confirm that it has committed the transaction.
getDecision(trans) → Yes / No

6
Call from participant to coordinator to ask for the decision on a transaction after it has
voted Yes but has still had no reply after some delay. Used to recover from server crash or
delayed messages.

Limitations of Two-Phase Commit protocol

1. Performance Overhead

2. Hazard Windows

(iii) Nested Transactions

A nested transaction is used to provide a transactional guarantee for a subset of

operations performed within the scope of a larger transaction. Doing this allows you to
commit and abort the subset of operations independently of the larger transaction.

The rules to the usage of a nested transaction are as follows:

 While the nested (child) transaction is active, the parent transaction may not
perform any operations other than to commit or abort, or to create more child
transactions.
 Committing a nested transaction has no effect on the state of the parent
transaction. The parent transaction is still uncommitted. However, the parent
transaction can now see any modifications made by the child transaction. Those
modifications, of course, are still hidden to all other transactions until the parent
also commits.
 Likewise, aborting the nested transaction has no effect on the state of the parent
transaction. The only result of the abort is that neither the parent nor any other
transactions will see any of the database modifications performed under the
protection of the nested transaction.
 If the parent transaction commits or aborts while it has active children, the child
transactions are resolved in the same way as the parent. That is, if the parent
aborts, then the child transactions abort as well. If the parent commits, then

7
 whatever modifications have been performed by the child transactions are also
committed.
 The locks held by a nested transaction are not released when that transaction
commits. Rather, they are now held by the parent transaction until such a time as
that parent commits.
 Any database modifications performed by the nested transaction are not visible
outside of the larger encompassing transaction until such a time as that parent
transaction is committed.
 The depth of the nesting that you can achieve with nested transaction is limited
only by memory.

Objective Type Questions

1. ACID stands for
a. Atomicity, Consistency, Isolation, Durability
b. Atomicity, Concurrency, Isolation, Durability
c. Availability, Consistency, Isolation, Durability
d. Availability, Concurrency, Isolation, Durability
2. Which property identifies that the transaction is atomic?
a. Atomicity
b. Consistency
c. Isolation
d. Durability

8
3. If the transaction has been successfully completed; all of the changes it made to
the system are permanent is called
a. Atomicity
b. Consistency
c. Isolation
d. Durability
4. Which transaction that span long periods of time?
a. Flat transaction
b. Distributed transaction
c. Nested transaction
d. Distributed Flat transaction
5. The transaction must travel across multiple sites to get to the resources it needs is
called
a. Flat transaction
b. Distributed transaction
c. Nested transaction
d. Distributed Flat transaction
6. A transaction is used to provide a transactional guarantee for a subset of
operations performed within the scope of a larger transaction is called
a. Flat transaction
b. Distributed transaction
c. Nested transaction
d. Distributed Flat transaction
7. In which property, after a transaction executes, it must leave the system in a
correct state or it must abort?
a. Atomicity
b. Consistency
c. Isolation
d. Durability
8. The changes that a transaction makes to shared resources must not become visible
outside the transaction until it commits is called

9
 a. Atomicity
b. Consistency
c. Isolation
d. Durability

Review Questions
Two Mark Questions
1. Define ACID property.
2. Define Atomicity, Consistency, Isolation, and Durability.
3. Define transaction.
4. What is meant by flat transaction, nested transaction, Distributed flat transaction.
Big Questions
1. Explain in detail the various transaction models.

TP Monitor
 TP (Transaction Processing) Monitors specialize in managing transactions
from their point of origin-typically on the client-across one or more servers
and then back to the originating client.
 When a transaction ends, the TP monitor ensures that all the systems involved
in the transaction are left in a consistent state.
 In addition, TP Monitors know how to run transactions, route them across
systems, load-balances their execution, and restart then after failures.
 It provides services that are required for OLTP applications.
 A TP monitor can manage resources on a single server or multiple servers, and
it can cooperate with other TP Monitors in federated arrangements. It also
provides a framework for running middle-tier server applications and
components.
 A TP monitor does three things:
1. Process management
2. Transaction Management
3. Client/Server Communications Management

10
(i) TP Monitors and OS
TP Monitors were introduced to run classes of applications that could service 100 and
sometimes 1000 of clients. If each of these 1000 of clients were given all the resources it
needed on a server- typically a communication connection, half a MB of memory, 1 or 2
processors, and a dozen open file handles. TP Monitors provide an OS-on top of the
existing OS’s that connects in real time these 1000 of impatient humans with a pool of
shared server’s processes-this is called funneling.

The “funneling act”is part of what a TP Monitor must do to manage the server side of a
user-written OLTP application. The server side of the OLTP application is typically
packaged as a dynamic library that contains a number of related functions. The TP
Monitor assigns the execution of the dynamic library functions to server classes, which
are pools of pre-started application processes or threads, waiting for work. Each process
or thread in a server class is capable of doing the work. The TP Monitor balances the
workload between them. Each application can have one or more server classes.

When a client needs a service request, the TP Monitor hands it to an available process in
the server class pool. The server process dynamically links to the DLL function called by
the client, invokes it, oversees its execution, and returns the results to the client. After that
completes, the server process can be reused by another client. The operating system keeps

11
the already loaded dynamic libraries in memory, where they can be shared across
processes.

In essence, the TP Monitor removes the process-per-client requirement by funneling

incoming client requests to shared server processes. If the number of incoming client
requests exceeds the number of processes in a server class, the TP Monitor may
dynamically start new ones—this is called load-balancing. The more sophisticated TP
Monitors can distribute the process load across multiple CPUs in SMP or MPP
environments. Part of the load-balancing act involves managing the priorities of the
incoming requests. The TP Monitor does that by running some high-priority server
classes and dynamically assigning them to the VIP clients.

Typically, short-running and high-priority functions are packaged in high-priority server

classes. Batch and low-priority functions are assigned to low-priority server classes. We
can also partition server classes by application type, desire response time, the resource
they manage, fault-tolerance requirements, and client/server interaction modes—
including queued, conversational, or RPC. In addition to providing dynamic load-
balancing, most TP Monitors let us manually control how many processes or threads are
available to each process class.

(ii) TP Monitors and Transaction Management

The transaction discipline was introduced in the early TP Monitors to ensure the
robustness of multi-user applications that ran on the servers. These applications had to be
bullet-proof and highly reliable if they were going to serve thousands of users in mission-
critical situations. TP Monitors were developed from the ground up as operating systems
for transactions. The unit of management, execution, and recovery was the ordinary
transaction and the programs that invoked them. The job of a TP Monitor is to guarantee
the ACID properties while maintaining high transaction throughput. To do that, it must
manage the execution, distribution, and synchronization of transaction workloads.

With TP Monitors, the application programmers do not have to concern themselves with
issues like concurrency, failures, broken connections, load-balancing, and the

12
synchronization of resources across multiple nodes. All this is made transparent to them
—very much like an operating system makes the hardware transparent to ordinary
programs. Simply put, TP Monitors provide the run-time engines for running transactions
—they do that on top of ordinary hardware and operating systems. They also provide a
framework for running server applications.

(iii) TP Monitor and Client/server Interaction Types

The types are:
 Conventional transaction
 RPC transaction
 Queued transaction
 Publish-and-Subscribe transaction
 Batch transaction
 Conventional and RPC transactions usually involve a human user that requires
immediate attention; they run in high-priority mode.
 Publish-and-Subscribe transaction runs as high priority messages too.
 Batch transactions run in low priority mode.
 MOM -based Queued transaction can be of either type.

Feature Non-Transactional Non-Transactional

Communications Communications
Participants Loosely coupled client/server Transactionally bound
programs client/server and server/server
programs. The message

13
 invocation causes the recipient
program to join the transaction
Commit No Yes
Synchronization
Only-once No Yes
semantics
Server No Yes. The process that receives
management on the message is started, load
the recipient balanced, monitored and tracked
node as part of the transaction
Load balancing Using directory services. No Uses the TP Monitor’s load
dynamic load balancing is balancing algorithms. Several
provided servers can read from the same
queue
Supervised No. Exchanges are simply between The TP Monitor supervises the
Exchanges client and server. Exchanges are entire ex change, restarts
transient. No crash recovery or communication links, redirects
error management is provided. messages to an alternate server
process if the first one gets hung,
performs retries, and provided
persistent queues and crash
recovery
TP Monitor standards

 XA

 OTS

 MTS/DTC

 EJB

TP Monitor Benefits
 Client/Server application development framework
 Firewalls of protection

14
  High availability
 Load balancing
 MOM integration
 Scalability of function
 Reduced system cost

Transactional RPC
Transactional RPCs are initiated from within the scope of a transaction. Each
transactional RPC does work on behalf of a transaction. It is RPC plus
 additional language constructs and run-time support to bundle several RPC calls
into an atomic unit
 extensions to databases and possibly other resource managers to allow them to
participate in a 2-phase commit process

In a transaction, either all operations succeed and an information system's state is updated
or all operations fail and the information system's state is unchanged. This means that if a
transaction has, for example, four operations and the third operation fails, the effect of
operations one and two must be rolled back.
Once the client ends a transaction, the transaction manager begins the two phase commit
process.
 First, the manager sends a prepare to commit message to each server participating
in the transaction
 Second, each server responds with either a ready to commit message or an
abort message (if failures occurred while processing its operation)
 Third, if all servers are ready to commit, the manager sends a commit message
and the client is notified that the transaction was successful.
 Otherwise, the manager sends an abort message to each server (which may then
have to perform a rollback) and the client is notified that the transaction failed.

TRPC consists of two components: a preprocessor and a library of functions. The TIDL
preprocessor, tidl, preprocesses interface definition files. It produces a set of files that

15
must be compiled and linked appropriately with client and the server programs. It also
produces an interface definition file that must be processed by IDL.

The library of functions provide the relevant communication support for the Distributed
Transaction Service (TRAN). TRPC also exports interface calls to the application
developer. The functions can be categorized into sets as follows:

 Functions to support the TRAN communication interface. The TRAN

communication interface is described in Transaction Service (TRAN). This aspect
of TRPC is not discussed in this document.
 Functions used to initialize the TRPC run time interface, provide information
about communication protocols and endpoints, and register callbacks (see
Application interface).

16
  Functions that wrap certain DCE RPC run time functions that manipulate RPC
handles

TRPC supports the following:

 Piggybacking data on an RPC

 Handling exceptions during the course of an RPC
 Aborting an RPC and the enclosed transaction
 Invoking functions at specific places in an RPC sequence

What is TP- Lite and TP-Heavy Monitors?

17
TP-Lite is simply the integration of TP Monitor functions in the database engines.
TP-Heavy is TP Monitors which supports the Client/Server architecture and allow PC to
initiate some very complex multiserver transaction from the desktop.

TP-Lite Versus TP-Heavy

TP-Lite and TP-Heavy is compared in:

1. TP-Lite Versus TP-Heavy: Scope of the Commit

2. TP-Lite Versus TP-Heavy: Managing Heterogeneous Resources
3. TP-Lite Versus TP-Heavy: Process Management
4. TP-Lite Versus TP-Heavy: Client/Server Invocations
1. TP-Lite Versus TP-Heavy: Scope of the Commit

TP-Lite stored procedure is written in a a database vendor procedural language and is

stored in the database. A stored procedure is a transactional unit but it can’t participate
with other transactional units in a global transaction. It can’t help the cause of
modularization or writing reusable functions.
In contrast, TP-Heavy procedures are written standard procedural languages. They can
easily provide all-or nothing protection in situations.
2. TP-Lite Versus TP-Heavy: Managing Heterogeneous Resources

18
A TP-Lite stored procedure can only commit transaction resources that are on the
vendor’s database or resource manager. It cannot synchronize or commit work that is on a
foreign database or resource manager-whether local or remote.
In contrast, TP-Heavy procedures can easily handle ACID updates on multiple
heterogeneous resource managers with in the scope of a single transaction.

3. TP-Lite Versus TP-Heavy: Process Management

A TP-Lite stored procedure gets invoked, executed under ACID protection and may then
be cached in memory for future reuse.
In contrast, TP-Heavy processes are pre started and managed as server classes. Server
classes run copies of the applications business logic-so they are ready to act on incoming
requests from clients. Loads are balanced across the server classes. If the load on a server
class gets too heavy, more processes are automatically started. Server classes support
priorities and other class of service attributes. It has firewalls around them that the
programs that run within them don’t interfere with each other.

19
4. TP-Lite Versus TP-Heavy: Client/Server Invocations
The TP-Lite stored procedure invocation is non-standard. Vendors provide their own
RPC invocation mechanism. The RPC’s are not defined using an IDL and they are not
integrated with global directory, security and authentication ser vices. The
communication links are not automatically restarted and they are not under transaction
protection. It does not support communications alternatives like conversations, queues or
publish-and-subscribe.
In contrast, TP-Heavy environment is very open to different communication styles. The
RPC can use DCE as its base. It also support peer-to-peer communications.

20
OBJECTIVE TYPE QUESTIONS

1. Which TP Monitors that supports the Client/Server architecture and allow

PC to initiate some very complex multi server transaction from the desktop

a. TP-lite

b. TP-heavy

c. None of the above

d. All the above

2. A network connecting computers and other devices with different operating

systems and/or protocols

a. homogeneous network

b. heterogeneous network

c. Mobile network

d. Local Area Network

3. TP Monitors provide an OS-on top of the existing OS’s that connects in real
time these 1000 of impatient humans with a pool of shared server’s processes-
this is called
a. funneling
b. TP-heavy
c. TP-lite
d. Process
4. Which transaction involves a human user that requires immediate attention;
they run in high-priority mode?
a. RPC transaction
b. Queued transaction

21
 c. Publish-and-Subscribe transaction
d. Batch transaction
5. Which transaction runs as high priority messages too?
a. RPC transaction
b. Queued transaction
c. Publish-and-Subscribe transaction
d. Batch transaction
6. Which transactions run in low priority mode?
a. RPC transaction
b. Queued transaction
c. Publish-and-Subscribe transaction
d. Batch transaction
7. One of the TP Monitor benefit is
a. Performance
b. Reliability
c. High availability
d. Throughput
8. Which TP monitors supports the Client/Server architecture and allow PC to
initiate some very complex multi server transaction from the desktop?
a. TP-lite
b. TP-heavy
c. TP and OS
d. TP-light
9. The integration of TP Monitor functions in the database engines is called
a. TP-lite
b. TP-heavy
c. None of the above
d. All the above

Review Questions

22
Two Mark Questions
1. Write short notes on TP monitor.
2. Differentiate TP- lite and TP-heavy monitor.
3. What do you meant by heterogeneous network?
4. Compare homogeneous network and heterogeneous network.
5. What is meant by process management?
6. What are the invocations of client server models?
7. What are benefits of TP Monitor?
8. Name any 4 TP Monitor standards.
9. What are the TP Monitor client/server interaction types?
10. How TP-lite is differentiated from TP-heavy in process management?
Big Questions

1. Explain in detail TP-monitor.

2. Compare TP-lite and TP-heavy.

ASSIGNMENT QUESTIONS

1. Define ACID property. Explain with one example.

2. Compare Homogeneous network and heterogeneous network.

1. Explain with example any 4 transaction types.

2. Discuss about the applications of Heterogeneous network.

1. Explain how the transactions in distributed systems.

2. How to manage homogeneous network?

23