1. Department of Computer Engineering
Poornima Institute Of Engineering and Technology
Department of Computer Engineering A
Presentation on
Presented By:
Mr. Manish Bhardwaj
Assistant Professor
PIET, Jaipur
TRANSACTION COMMUNICATION
Lecture No-17
Subject Code -8 CS3
Subject Name- DS

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
centralized system
DBMS
presentation application
services services
user module
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)

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
communication
central machine
presentation application
services services
• • •
DBMS
presentation application
services services
user module
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. What is Transactions
A transaction is specified by a client as a set of operations on objects to be performed as an indivisible unit by the servers managing those objects.
The servers must guarantee that either the entire transaction is carried out and the results recorded in permanent storage or, in the case that one or more of them crashes, its effects are completely erased.

8. Transactions (ACID)
Atomic: All or nothing. No intermediate states are visible.
Consistent: system invariants preserved, e.g., if there were n dollars in a bank before a transfer transaction then there will be n dollars in the bank after the transfer.
Isolated: Two transactions do not interfere with each other. They appear as serial executions.
Durable: The commit causes a permanent change.

9. What is Required? Transactions
Clusters a sequence of object requests together such that they are performed with ACID properties
i.e transaction is either performed completely or not at all
leads from one consistent state to another
is executed in isolation from other transactions
once completed it is durable
Used in Databases and Distributed Systems
For example consider the Bank account scenario from last session

10. Scenario Class Diagram
DirectBanking
+funds_transfer(from:Account,
to:Account,amount:float)
Account
-balance:float =0
+credit(amount:float)
+debit(amount:float)
+get_balance():float
InlandRevenue
+sum_of_accounts(
set:Account[]):float
The class diagram shows the types of objects that participate in the example transactions, that we will use in this lecture. The examples will use objects of type Account, which have internal state. The state captures the balance of the account as a float number. Objects of type Account can debit and credit a sum to the account and use get_balance to find out what an account is currently holding
A funds transfer involving a debit operation from one account and a credit operation from another account would be regarded as a transaction
Both operations will have to be executed or not at all.
They leave the system in a consistent state.
They should be isolated from other transactions.
They should be durable, once transaction is completed.

11. Transaction Concepts ACID Properties
Atomicity
Consistency
Isolation
Durability
Transaction Commands: Commit vs. Abort
Identify Roles of Distributed Components
Flat vs. Nested Transactions
In this part, we are going to define a number of concepts that are related to transactions.
The first set of concepts are the properties transactions have. These properties are commonly referred to as ACID properties.
We are then going to review typical transaction commands by means of which a component can start and end a transaction.
After that we are going to identify different roles that distributed components can play in the execution of a distributed transaction. We will see that there are transactional clients that request a transaction to be started and transactional servers that manage resources that are accessed and modified during a transaction. A transaction coordinator manages the overall processing of a transaction.
Finally, we are going to introduce nested transactions which are transactions that are not started by a transactional client, but that are started within a transaction.

12. Atomicity
Transactions are either performed completely or no modification is done.
I.e perform successfully every operation in cluster or none is performed
e.g. both debit and credit in the scenario
Start of a transaction is a continuation point to which it can roll back.
End of transaction is next continuation point.
Transactions are sequences of operations that are clustered together.
The atomicity property of a transaction requires that this cluster is either performed completely, i.e. every single operation belonging to the transaction is successfully executed, or not at all. There is not a partial execution of the transaction.
Let us consider the example of the cash transfer and assume that we perform it as a transaction. Atomicity then achieves that either both the debit and the credit operation are executed together (meaning that the money is being successfully transferred to the target account) or none of the operation is done (meaning that the money is left where it was). A state where money is lost cannot occur.
The start of a transaction is a continuation point to which the transaction rolls back if a single of its operations fails.
If the transaction is completed successfully, the end of the transaction (which is usually the start of the next transaction) marks the next continuation point.

13. Consistency Shared resources should always be consistent.
Inconsistent states occur during transactions:
hidden for concurrent transactions
to be resolved before end of transaction.
Application defines consistency and is responsible for ensuring it is maintained.
e.g for our scenario, consistency means “no money is lost”: at the end this is true, but in between operations it may be not
Transactions can be aborted if they cannot resolve inconsistencies.
The consistency property of a transaction requires that the sequence of operations leaves the set of shared resources in a consistent state at the end of the transaction.
This does not exclude that states of inconsistency occur at all, but their occurrence is confined to within a transaction. As such inconsistent states are hidden for concurrent transactions and they are to be resolved before the transaction is completed.
Revisiting the example of the cash transfer, a consistency constraint would be that money is not lost. This is true at the end of the transaction when the money that has been debited to one account has been credit to the other. Within the transaction, after the debit has been completed but before the credit has been executed, the set of account objects are in an inconsistent state as the money is on neither accounts.
Hence it is the application that defines the notion of consistency and it is also the application that is in charge of ensuring consistency maintenance.
If the transaction has reached a certain state of inconsistency that cannot be resolved, it can abort itself and recover to the consistent state when it started. Considering our cash transfer example again, if the money has been debited to one account but the other account is not reachable, the transaction can abort and the transaction mechanism will recover the first account object to the state where the money is still on it.

14. Isolation
Each transaction accesses resources as if there were no other concurrent transactions.
Modifications of the transaction are not visible to other resources before it finishes.
Modifications of other transactions are not visible during the transaction at all.
Implemented through:
two-phase locking or
optimistic concurrency control.
The isolation property of a transaction requires that the sequence of operation is performed in isolation to any concurrent transaction or unprotected activity.
This means also, that any modifications that a transaction does are not visible to other resources before the end of the transaction. In that way other transactions or unprotected activities can never see an inconsistent state that may arise within a transaction.
Likewise, it means that operations performed as a transaction can never access modifications of other concurrent transactions.
It is also worthwhile to note that isolation of transactions is usually implemented with exactly those techniques for concurrency control that we have introduced in the last session, namely two phase locking or optimistic concurrency control.

15. Durability
A completed transaction is always persistent (though values may be changed by later transactions).
Modified resources must be held on persistent storage before transaction can complete.
May not just be disk but can include properly battery-backed RAM or the like of EEPROMs.
The durability property requires the effect of a transaction to be persistent so that it cannot be affected by failures.
This requires to keep a copy of all modified resources or a representation of the modifications (a so called log) on persistent storage. Then this persistent representation can be used after a failure to recover to the state of the last completed transaction.
In case of the transaction between the two account object a transaction manager would either update a persistent representation of the two account objects during the end of the transaction, or it would add representations of the operation executions, i.e. the debit and the credit operation with the actual parameter values, to a persistent log.
Although hard disks are most commonly used to achieve persistent storage this need not necessarily be the case. It could also be a RAM that is battery backed up or an erasable PROM.

16. Transaction Commands Begin: Commit: Abort: Start a new transaction.
End a transaction.
Store changes made during transaction.
Make changes accessible to other transactions.
Abort:
Undo all changes made during the transaction.
There are three commands or operations to manipulate a transaction: begin, commit and abort.
Begin (sometimes also referred to as open) marks the beginning of a new transaction.
Commit (sometimes also referred to as end or close) ends a transaction. It takes care that all modifications of the transaction are stored persistently and that the changes become accessible to concurrent transactions. With pessimistic techniques, the commit would, therefore, release all locks and with optimistic techniques the commit would start the validation phase.
Abort (sometimes also referred to as rollback or undo) ends a transaction, but does not make the changes persistent. On the contrary, it recovers the state the resources had when the transaction started.
To continue our cash transfer example, the component implementing the transfer would issue a start command, then do the debit and credit operation and would then commit the changes, making them persistent and visible to concurrently executing transactions.

17. Roles of Components
Distributed system components involved in transactions can take role of:
Transactional Client
Transactional Server
Coordinator
The components that are involved in a transaction usually have different roles. They can take the role of a transactional client, a transactional server and that of a transaction coordinator.
A transactional client is a component that starts and commits transactions. In the cash transfer example, the component implementing the transfer and invoking the credit and debit operations would be a transactional client.
A transactional server is a component that executes operations as parts of transactions. In the cash transfer example, the account object would be a transactional server as it maintains resources (the account balance) that is modified under transaction control.
A Transaction coordinator is a component that controls the execution of a transaction. It exports the start, commit and abort transaction commands to the transactional client. In the cash transfer example, the component from which the transactional client would invoke the start and end transaction operations is the transaction coordinator.

18. Coordinator Coordinator plays key role in managing transaction.
Coordinator is the component that handles begin / commit / abort transaction calls.
Coordinator allocates system-wide unique transaction identifier.
Different transactions may have different coordinators.
The transaction coordinator is the component that offers the transaction commands/operations to transactional clients.
It allocates system-wide unique transaction identifiers. These transaction identifiers are used during the communication between transaction coordinator and transactional servers.
Note, that there is not necessarily a single transaction coordinator in a distributed setting. Having such a centralised coordinator would, in fact, be rather counter-productive as it might create a serious performance bottleneck. Hence different transactions may well have different coordinators which do not need to know of each other.

19. Transactional Server
Every component with a resource accessed or modified under transaction control.
Transactional server has to know coordinator.
Transactional server registers its participation in a transaction with the coordinator.
Transactional server has to implement a transaction protocol (two-phase commit).
Distributed system components that have resources that ought to be accessed and/or modified under transaction control have the role of a transactional server.
A transactional server knows the coordinator of the transaction the server is participating in. Identification of the coordinator is usually based on unique transaction identifiers that either transactional clients pass as arguments to the transactional servers or that are obtained from some component that manages a current transaction context. In the former case, the transactional clients obtain the transaction identifiers from the transaction coordinator when they begin or end a transaction.
Transactional servers then register with the transaction coordinator in order to inform the coordinator that they are participating in a transaction.
The transactional servers also have to implement a number of operations that the transaction coordinator can invoke in order to implement a transaction protocol. We shall discuss a two-phase commit protocol later, but you should remember at this stage that a transaction protocol involves cooperation between the transaction coordinator and all the transactional servers participating in a transaction.

20. Transactional Client
Only sees transactions through the transaction coordinator.
Invokes services from the coordinator to begin, commit and abort transactions.
Implementation of transactions are transparent for the client.
Cannot tell difference between server and transactional server.
Transactional clients only see transactions through the coordinator.
Transactional clients request transaction start, commit and abort from the coordinator.
In our cash transfer example, the application that funds transfer application that invokes the credit and debit operations would be the transactional client.
The implementation of transactions is transparent to clients. Hence this contributes to achieving failure transparency for clients.
It is also transparent for a client, whether a component is a server (meaning that it does not participate in transactions) or a transactional server. Hence, clients use the same commands and operation signatures within and without transactions.

21. Flat Transactions Flat Transaction Flat Transaction Flat Transaction
Begin
Trans.
Commit
Flat Transaction
Begin
Trans.
Begin
Trans.
Abort
Crash
Flat Transaction
Flat Transaction
Rollback
Rollback

22. Two-Phase Commit
Committing a distributed transaction involves distributed decision making.Communication defines commit protocol
Multiple autonomous distributed servers:
For a commit, all transactional servers have to be able to commit.
If a single transactional server cannot commit its changes, then every server has to abort.
Single phase protocol is insufficient.
Two phases are needed:
Phase one: Voting
Phase two: Completion.
Now we have identified the key concepts of transactions and can start focussing on the techniques used for the implementation of transactions.
In the setting we assume in this module, we have multiple autonomous transactional servers that are distributed over a number of processors connected via a network. In particular there is no single point of control. To achieve the atomicity property of transactions, however, all transactional servers have to be able to commit. If a single transactional server cannot commit the changes made during the transaction and guarantee their durability the whole transaction must not be committed. Otherwise it would not be atomic. Henceforth, if a single transactional server cannot commit the whole transaction has to be aborted.
The transaction coordinator cannot achieve this by contacting all the transactional servers that participated in the transaction only once. This is because every single server may fail to be able to commit and then the servers the coordinator has contacted earlier must not commit either.
Hence two phases are needed for implementing transactions with autonomous and distributed servers. Within the first phase the coordinator would ask the servers whether they are able to commit. This is the voting phase. If all servers agree to commit, the coordinator can ask them to complete the transaction in the second phase. This is why this protocol is called two-phase commit protocol.
Note that this protocol is only needed in a distributed setting and centralised database systems, for instance, can implement transaction with a considerably simpler protocol.

23. Two Phase Commit Protocol

24. Phase One Called the voting phase.
Coordinator asks all servers if they are able (and willing) to commit.
Servers reply:
Yes: it will commit if asked, but does not know yet if it is actually going to commit.
No: it immediately aborts its operations.
Hence, servers can unilaterally abort but not unilaterally commit a transaction.
Let us now review the two phases in more detail. The first phase is called the voting phase.
During this phase, the transaction coordinator contacts all the transactional servers that have registered themselves during the course of the transaction and asks them whether they are able and willing to commit.
Servers reply during this phase with either yes or now. If they reply yes it means that they are able to commit and will do so if they are asked to. The server, however, does not know yet whether it is going to commit because it may happen that the coordinator receives a now from another server later. In order to be able to commit, the server will have to keep all the modified resources on persistent storage as the server may die and have to be restarted before the commit is invoked. If the server replies no to the vote, it can abort and recover to the state it had at the start of the transaction.
Hence transactional servers can unilaterally abort an operation but it requires consensus among all servers involved in a transaction in order for them to commit.

25. 3 Phase Two Called the completion phase.
Co-ordinator collates all votes, including its own, and decides to
commit if everyone voted ‘Yes’.
abort if anyone voted ‘No’.
All voters that voted ‘Yes’ are sent
‘DoCommit’ if transaction is to be committed.
Otherwise ‘Abort'.
Servers acknowledge DoCommit once they have committed.
The second phase is the completion phase. During this phase, the transaction coordinator collates all the vote of the transactional servers. The transaction coordinator has a vote itself and it also includes its vote. For the transaction to be committed the vote has to be unanimous in favour of committing. If a single server votes against committing the transaction it has to be aborted.
If the transaction is to be completed, all servers will receive a request to perform the commit and then the servers can make the changes persistent and globally visible. Otherwise they receive a request to abort the transaction. They acknowledge the successful commit to the server.

26. Flat and Nested Transactions

27. Flat Banking Transactions

28. Nested Banking Transactions

29. Operation for Two Phase Commit Protocol

31. Communication in 2PC

32. Object Request for 2 Phase Commit
:Resource
:Resource
:Coordinator
begin()
debit()
register_resource()
credit()
register_resource()
commit()
vote()
The sequence diagram shows the two phase commit for a distributed fund s transfer transaction between two accounts residing on the hosts of different banks.
First the transactional client requests the begin of a new transaction from the transactional coordinator. Then the transactional client invokes debit and credit operations from the two account objects that are transactional servers.
The implementation of these two operations know that they are part of a transaction and they therefore register their transaction involvement with the coordinator .
The client then requests execution of commit.
To implement the commit, the coordinator first asks the two account objects for their vote to commit.
In this example, both transactional servers vote in favour of the commit and the coordinator requests the doCommit operation from them.
The coordinator then returns control to the client, indicating that the transaction was completed successfully.
vote()
doCommit()
doCommit()

33. Server Uncertainty
Period when a server is able to commit, but does not yet know if it has to.
This period is known as server uncertainty.
Usually short (time needed for co-ordinator to receive and process votes).
However, failures can lengthen this process, which may cause problems.
Solution is to store changes of transaction in temporary persistent storage e.g. log file, and use for recovery on restarting.
From the point of view of a transactional server, there is a certain period of uncertainty after it has issued a positive vote and the invocation of the commit request. This period is referred to as server uncertainty.
In general, this period is fairly short but it is still possible that failures occur during that period and provisions have to be made to cope with these failures.
Once the coordinator has started to issue commit requests, the transaction has to be completed by all means. It cannot be aborted because some servers have completed already and for the transaction to be atomic all other servers must complete.
Hence the transaction coordinator has to be built in a way that it can cope with these failures.

34. Recovery in Two-Phase Commit
Failures prior to the start of 2PC result in abort.
If server fails prior to voting, it aborts.
If it fails after voting, it sends GetDecision.
If it fails after committing it (re)sends HaveCommitted message.
If a failure happens before the start of the voting, it results in an implicit abort as transactional servers have not made their changes persistent and visible.
If the coordinator fails prior to transmitting the commit messages it results in an implicit abort as well, as the servers have not received commits and still have not made their changes persistent and visible.
However, if a failure happens during the processing of the commit requests, the coordinator is in charge to recover after the failure, to restart the servers and have them performing the outstanding commits. This is why the servers have to make provisions while giving a positive vote and store the state of modified resources on persistent storage. The coordinator then retransmits all commit messages on restart. This also requires that the coordinator keeps the information which servers participated in a transaction on persistent storage.
If a transactional server fails prior to voting, it will not be reachable and the coordinator will interpret this as a negative vote and it will then abort the whole transaction.
If a server fails after voting but before committing, the server will ask the coordinator after restart for the result of the ballot and act accordingly.
If the server fails after having committed, the server resends the acknowledgement of the commit after restart in order to make sure that the coordinator is informed that the server has committed successfully.

35. Recovery in Two-Phase Commit
Coordinator failure prior to transmitting DoCommit messages results in abort (since no server has already committed).
After this point, co-ordinator will retransmit all DoCommit messages on restart.
This is why servers have to store even their provisional changes in a persistent way.
The coordinator itself needs to store the set of participating servers in a persistent way too.
If a failure happens before the start of the voting, it results in an implicit abort as transactional servers have not made their changes persistent and visible.
If the coordinator fails prior to transmitting the commit messages it results in an implicit abort as well, as the servers have not received commits and still have not made their changes persistent and visible.
However, if a failure happens during the processing of the commit requests, the coordinator is in charge to recover after the failure, to restart the servers and have them performing the outstanding commits. This is why the servers have to make provisions while giving a positive vote and store the state of modified resources on persistent storage. The coordinator then retransmits all commit messages on restart. This also requires that the coordinator keeps the information which servers participated in a transaction on persistent storage.
If a transactional server fails prior to voting, it will not be reachable and the coordinator will interpret this as a negative vote and it will then abort the whole transaction.
If a server fails after voting but before committing, the server will ask the coordinator after restart for the result of the ballot and act accordingly.
If the server fails after having committed, the server resends the acknowledgement of the commit after restart in order to make sure that the coordinator is informed that the server has committed successfully.

36. Transaction Example: Funds Transfer
(Resource)
(Resource)
Current
Coordinator
begin()
debit()
get_control()
register_resource()
credit()
get_control()
register_resource()
commit()
This slide shows the interactions between transactional clients, transactional servers and the transaction coordinators in a distributed transaction as it is supported by the object transaction service. The example is, once again, the cash transfer example between two account objects that reside on different servers (say one at Barclays and another one at NatWest).
The client in this example is once again the funds transfer application. It would invoke the begin operation from the transaction coordinator through the Current interface.
It would then invoke the debit operation from the first bank account object in order to withdraw money from that account. The bank account object would be a transaction aware resource and, in fact, be a transactional server. As such it would register itself with the transaction coordinator for the current transaction. It obtains an object reference to the coordinator through the the get_control operation of the Current interface. The second account object would do very much the same when the credit operation is invoked (except that it credits the amount to the balance, of course).
Please note that both account objects would not make any permanent and durable changes yet the credit and debit operations would just note the new balance on a private instance variable. The persistent representation of the balance would not be touched.
Then the transactional client issues the commit operation through the Current account and this leads to the situation that the coordinator starts the two-phase commit protocol, collects the votes and if both objects can commit invokes the commit operation. Only then would the two objects make the changes of the balance persistent.
prepare()
prepare()
commit()
commit()

37. CORBA Transaction Service
Application
Objects
CORBAfacilities
Object Request Broker
CORBAservices
Transaction

38. IDL Interfaces
Object Transaction Service defined through three IDL interfaces:
Current (transaction interface)
Coordinator
Resource (transactional servers)
The interfaces to CORBAservices are all defined in IDL. Hence the Object Transaction service defines IDL interfaces for CORBA objects that are involved in transactions.
The transaction coordinator as we have introduced it above is specified through two interfaces: Current and Coordinator.
The Current interface specifies operations through which transactional clients access transaction operations to start, commit or abort a transaction.
The Coordinator interface specifies the coordination operations that are used by transactional servers (resources in the CORBA terminology).
Finally, the Resource interface specifies operations that are to be redefined by transactional servers in order to implement the two-phase commit protocol.

39. Current – Implicit Current Tx
interface Current {
void begin() raises (...);
void commit (in boolean report_heuristics)
raises (NoTransaction, HeuristicMixed,
HeuristicHazard);
void rollback() raises(NoTransaction);
Status get_status();
string get_transaction_name();
Coordinator get_control();
Coordinator suspend();
void resume(in Coordinator which)
raises(InvalidControl); };
(every CORBA object has an implicit transaction associated with it)
Interface Current defines the operations that transactional clients use to manipulate transactions.
Operation begin starts a new transaction. If a transaction has been started before, it starts a sub-transaction of the previously started transaction.
Operation commit ends a (sub)transaction. If the transaction is the root transaction, all changes are made durable.
Operation rollback reverts all resources participating in the (sub)transaction to the state they had when the transaction started.
The operation get_control provides an identifier for the CORBA object that is the transactional coordinator´s interface.
Operation suspend stops the execution of a transaction (without aborting it). It returns an identifier of a coordinator which can be used as an argument to the operation resume, which continues the execution of that transaction.

40. Coordinator – Explicit Tx Coordinator
interface Coordinator {
Status get_status();
Status get_parent_status();
Status get_top_level_status();
boolean is_same_transaction(in Coordinator tr);
boolean is_related_transaction(in Coordinator tr);
RecoveryCoordinator register_resource(
in Resource r) raises(Inactive);
void register_subtran_aware(
in subtransactionAwareResource r)
raises(Inactive, NotSubtransaction);
... };
This slide presents an excerpt of the Coordinator interface, which is also part of the transactional coordinator and is used by transactional servers.
The two most important operation of the coordinator interface are register_resource and register_subtran_aware. They add a transactional server (i.e. a resource) that is passed as an argument to the set of those resources that participate in a transaction or a subtransaction.
The other operations can be used by the transactional servers to obtain status information of the transaction, its parent or the root transaction.

41. Resource interface Resource {
Vote prepare(); // ask the resource/server to vote
void rollback() raises(...);
void commit() raises(...);
void commit_one_phase raises(...);
void forget(); };
interface SubtransactionAwareResource:Resource {
void commit_subtransaction(in Coordinator p);
void rollback_subtransaction();
This slide displays the interfaces of resources (i.e. transactional servers).
Those resources that participate in flat transactions have to be defined as subtypes of Resource and those transactional servers that participate in subtransactions have to be subtypes of SubtransactionAwareResource.
They then have to redefine the operations prepare, rollback, commit, commit_one_phase and forget.
In the implementation of these operations transactional servers would then implement their part of the two phase commit protocol.
Note, that it is not transparent to implementations of objects whether they can participate in a transaction. Unfortunately, it is also not transparent to clients whether an object is transaction aware as the inheritance relationship is exposed at the interface level.