1. Distributed Systems Topic 7: Transactions and Distributed Transactions
Michael R. Lyu
Computer Science & Engineering Department
The Chinese University of Hong Kong
In the last topic we have discussed and compared optimistic and pessimistic concurrency control techniques. It is often necessary to identify certain “units” for concurrency control.
In the current topic we are going to look at transactions and we are going to see that transactions are very often used to identify the units for concurrency control. Another major motivation to cluster operations to units is to make them atomic in order to have them either performed completely or not at all. This is a very important primitive to protect the integrity of components against hardware or software failures.
Hence, the question that we are going to focus on this topic is: How can the integrity of components be preserved during concurrent accesses, in the presence of hardware or software failures?
This is rather important in a distributed setting, since there are multiple points of control, and also multiple points of failure.

2. Outline 1 Motivation 2 Transaction Concepts 3 Two Phase Commit
4 Distributed Transactions and Deadlocks
5 Summary
In the first part we shall motivate why we are looking at the issue of transactions and how they are being used.
In the second part, we are going to introduce the basic transaction concepts, such as atomicity, consistency, isolation and durability that are commonly referred to as ACID properties of transactions. We are also going to look at nesting of transactions.
After that, we are going to introduce a transaction protocol that is referred to as two phase commit (and should not be confused with two phase locking). Two phase commit is needed to end a distributed transaction.
We will also address distributed transactions and distributed deadlocks.
As usual, a summary points out the learning goals and indicates the textbook chapter for your background reading.

3. 1 Motivation
What happens if a failure occurs during modification of resources?
Which operations have been completed?
Which operations have not (and have to be done again)?
In which states will the resources be?
Whatever measures are taken to avoid failures, failures still occur. Power supplies may fail, disks crash when they have been used long enough and also operating systems may be trashed with garbage and run out of resources when they are in use for long periods.
Assume that such a failure occurs while a component updates resources from other components, say during the money transfer between bank accounts we discussed in the previous topic. That transfer consisted of two primitive operation invocations: a credit and a debit operation.
Now if a failure occurs during the money transfer, a number of questions arise:
Which operations have been completed and which have not? In case of the cash transfer, has the debit operation been completed but the credit operation not?
What is the state of the resources? Are any operations necessary to restore their integrity? In the case of the cash transfer has money that was on its way from one account to the other account been lost and does it need to be recovered?
The approach taken in both databases and distributed systems to deal with these problems are transactions. A transaction is a sequence operation that is either performed completely or not at all. If it is completed, the effect of a transaction is persistent and cannot be affected by failures.

4. 1 Revisit of Funds Transfer Example
Funds transfer from Acc1 to Acc2: t0 t1 t2 t3 t4
Time
Balances at t0 Acc1: 7500, Acc2: 0 t5 t6 t7
Acc1->debit(7500):
Acc1->lock(write);
Acc1.balance=0;
Acc1->unlock(write);
Acc2->credit(7500):
Acc2->lock(write);
Acc2.balance=7500;
Acc2->unlock(write);
This slide revisits the fund transfer example we discussed in our last lecture. We assume that at the beginning of the scenario, the balance of account Acc1 is $7500, while the other account Acc2 does not contain any money. The scenario assumes that there is a funds transfer process that transfers the sum of $7500 from Acc1 to Acc2. The transfer is implemented by invoking the debit operation on Acc1 and the credit operation on Acc2. The corresponding locking mechanism is in place to assure concurrency control.

5. 1 Funds Transfer in Concurrency
Funds transfer from Acc1
Funds transfer to Acc2 t0 t1 t2 t3 t4
Time
Balances at t0 Acc1: 7500, Acc2: 0 t5 t6 t7
Acc1->debit(7500):
Acc1->lock(write);
Acc1.balance=0;
Acc1->unlock(write);
Acc2->credit(7500):
Acc2->lock(write);
Acc2.balance=7500;
Acc2->unlock(write);
In the funds transfer example since there is no conflict of locks between Acc1 and Acc2, the debit operation in Acc1 can occur concurrently with the credit operation in Acc2. In fact, as Acc1 and Acc2 are often two separate accounts in two remotely located banks, it is most likely that the will execute in parallel.
In normal operations, there would be no problem as there is no lock conflict in the concurrency control. But what if a failure occur to either side of the process? If the left-side operation aborts due to a failure to the server which handles Acc1 operations, and right-side operation is successful as there is no failure to the server which handles Acc2 operations, then both account will contain 7500 dollars. This would not be acceptable operations.
In order to assure the correct operations of two dependent operations occurring in two distributed components, we need to introduce the concept of transactions.

6. 2 Transaction Concepts 1 ACID Properties
Atomicity
Consistency
Isolation
Durability
2 Transaction Commit vs. Abort
3 Roles of Distributed Components
4 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.

7. 2.1.1 Atomicity
Transactions are either performed completely or no modification is done.
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.

8. 2.1.2 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.
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.

9. 2.1.3 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 topic, namely two phase locking or optimistic concurrency control.

10. 2.1.4 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.
Wide use of hard disks.
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.

11. 2.2 Transaction Commands Begin: Commit: Abort:
Start a new transaction.
Commit:
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.

12. 2.3 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.

13. 2.3.1 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 centralized 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.

14. 2.3.2 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.

15. 2.3.3 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.

16. 2.4 Distributed Transactions
(a) Flat transaction
(b) Nested transactions M X T 11 X
Client T N T 1 T Y 12 T T T
A client transaction becomes distributed if it invokes operations in several different servers. There are two different ways that distributed transactions can be structured: as flat transactions and as nested transactions.
In a flat transaction, a client makes requests to more than one server.
In this slide part (a), transaction T is a flat transaction that invokes operations on objects in servers X, Y and Z. A flat client transaction completes each of its requests before going on to the next one. Therefore, each transaction accesses servers’ objects sequentially.
In a nested transaction, the top-level transaction can open subtransactions, and each subtransaction can open further subtransactions down to any depth of nesting.
In this slide part (b), a client’s transaction T opens two subtransactions T1 and T2, which access objects at servers X and Y. The subtransactions T1 and T2 open further subtransactions T11, T12, T21 and T22, which access objects at servers M, N and P. In the nested case, subtransactions at the same level can run concurrently. That is T1 || T2, T11 || T12 || T21 || T22. Note T12 and T21 share the same server N.
Example: Funds Transfer can either be in flat transaction, or in nested transactions for concurrency purpose. 21 T 2
Client Y P Z T 22

17. 2.4 Flat Transactions Flat Transaction Commit Begin Abort Trans. Crash
Rollback
Begin
Trans.
Abort
Let us consider the difference between flat and nested transactions in terms of their transaction commands.
In a flat transaction a transactional client issues begin transaction, commit transaction or abort transaction commands.
The transaction is successfully completed if it reaches the commit statement.
The transaction is not completed if it is either explicitly aborted by the transactional client (if it encounters an inconsistency that cannot be reconciled) or it is implicitly aborted if a system failure occurs and it does not reach the commit.
In a flat transaction it is not possible to start a transaction within a transaction. For a transaction to be started there must not be an ongoing transaction.

18. 2.4 Nested Transactions Main Transaction Begin Trans. Call Commit
In nested transactions, transactions may have so called subtransactions.
The objective of having subtransactions is to be able to set save points within a transaction in order to revert to these save points. If an unreconcileable inconsistency is reached, it then becomes possible to undo only a part rather than the whole transaction by aborting only the subtransaction that caused the inconsistency. The parent transaction then continuous at the point where the aborted subtransaction was started.
To start a subtransaction, transactional clients invoke a begin transaction operation from the transaction coordinator during the course of a parent transaction. With nested transactions it is, therefore, permitted to have a begin transaction operation without having completed the previous transaction and such a begin will launch a subtransaction.
Subtransactions can have subtransactions of their own, leading to an arbitrary deep nesting hierarchy.
If a parent transaction is aborted, however, the effect of all its completed subtransactions is undone. Consequently, if the root transaction is aborted all commited subtransactions are undone.

19. 3 Two-Phase Commit 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 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 centralized database systems, for instance, can implement transaction with a considerably simpler protocol.

20. 3.1 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 yet know 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 no. 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 no 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.

21. 3.1 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.

22. 3.1 Server Uncertainty
Period when a server must be able to commit, but does not yet know if has to.
This period is known as server uncertainty.
Usually short (time needed for coordinator to receive and process votes).
However, failures can lengthen this process, which may cause problems.
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.

23. 3.2 Recovery in Two-Phase Commit
Failures prior to start of 2PC results in abort.
Coordinator failure prior to transmitting commit messages results in abort.
After this point, coordinator will retransmit all commit messages on restart.
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.

24. 3.2 Complexity Assuming N participating servers:
(N-1) Voting requests from coordinator to servers.
(N-1) Votes from servers to coordinator.
At most (N-1) Completion requests from coordinator to servers.
(When commit) (N-1) acknowledgement from servers to coordinator.
Hence, complexity of requests is linear in the number of participating servers.
Let us now consider the complexity of the two-phase commit protocol. When discussing complexity, one is interested in the order of magnitude with which some algorithm performs depending on some input variables.
In the case of the two-phase commit protocol, the variable size is the number of participating servers. Let us therefore assume that we have a finite number of N transactional servers (including the coordinator).
Then the coordinator needs to contact N-1 servers and request a vote from them (it does not need to contact itself) and it needs to send N-1 completion requests.
Hence, the complexity is 4 * O(N-1) = 4 * O(N) = O(N). This means that the complexity increases linear with the number of servers (neglecting constant factors).

25. 3.3 Committing Nested Transactions
Cannot use same mechanism to commit nested transactions as:
subtransactions can abort independent of parent.
subtransactions must have made decision to commit or abort before parent transaction.
Top level transaction needs to be able to communicate its decision down to all subtransactions so they may react accordingly.
The two-phase commit protocol we have discussed so far works for flat transactions that involve autonomous and distributed transactional servers.
For committing nested subtransactions we cannot use the same mechanisms as for flat transactions because subtransactions can abort independently from their parent transaction. Also subtransactions must have made a decision to commit or abort before the parent transaction can decide.
Moreover, the top level transaction needs to be able to communicate its decision down to all subtransactions so that they react accordingly. If the top-level transaction decides to abort, even committed subtransactions must undo modifications they have done to resources.

26. 3.3 Provisional Commit Subtransactions vote either:
aborted or
provisionally committed.
Abort is handled as normal.
Provisional commit means that coordinator and transactional servers are willing to commit subtransaction but have not yet done so.
The approach taken to solve this problem is to introduce another state for subtransactions. This state is referred to as a provisional commit
A provisional commit means that the subtransaction has been successfully completed but has not finally committed. For the final commit it awaits a directive from its parent transaction.
A provisionally committed subtransaction may still abort if its parent transaction is aborted. This means also that data managed by subtransaction-aware servers has to be kept in a way that the old state of the server can still be restored after the provisional commit.

27. 3.3 Example for A Nested Transaction1 2 T 11 12 22 21
abort (at M)
provisional commit (at N)
provisional commit (at X)
aborted (at Y)
provisional commit (at P)
This slides shows how Transaction T decides whether to commit or not, based on the nested transaction example in slide 2.4 part (b). Each subtransaction has either provisionally committed or aborted. For example, T12 has provisionally committed and T11 has aborted, but the fate of T12 depends on its parent T1 and eventually on the top-level transaction T. Although T21 and T22 have both provisionally committed, T2 has aborted and this means that T21 and T22 must also abort. Suppose that T decides to commit in spite of the fact that T2 has aborted, also that T1 decides to commit in spite of the fact that T11 has aborted.
When a top-level transaction completes, its coordinator carries out a two-phase commit protocol. When each subtransaction was created, it joined its parent transaction. It can report status when provisionally commits or aborts. Eventually the top-level transaction receives a list of all subtransactions in the tree, together with the status of each. Descendants of aborted subtransactions are actually omitted from this list.

28. 3.3 Information Held by Coordinators
Coordinator of
transaction
Child
transactions
Participant
Provisional
commit list
Abort list T 1
, T 2
yes 12 11 21 22
no (aborted)
but not
no (parent aborted)
This slide shows the information held by coordinators of nested transactions. Note that T12 and T21 share a coordinator as they both run at server N. When subtransaction T2 aborted, it reported the fact to its parent T without passing on any information about T21 and T22. A subtransaction is an orphan if one of its ancestors aborts, either explicitly or because its coordinator crashed.
Subtransactions T21 and T22 are orphans because their parent aborted without passing information about them to the top-level transaction.

29. 3.3 Two-Phase Commit for Nested Transactions
For nested transactions, the top-level transaction plays as coordinator, while participants are all the provisionally committed subtransaction coordinators without aborted ancestors.
Hierarchic two-phase commit: a multi-level nested protocol where the coordinator communicates to the immediate child transaction coordinator in a hierarchic fashion.
Flat two-phase commit: the coordinator contact all participants with provisional commit directly.
The top-level transaction plays the role of coordinator in the two-phase commit protocol, and the participant list consists of the coordinators of all the subtransactions in the three that have provisionally committed but do not have aborted ancestors.
By this stage, the logic of the program has determined that the top-level transaction should try to commit whatever is left, in spite of some aborted subtransactions.
The coordinators of T, T1 and T12 are participants and will be asked to vote on the outcome. If they vote to commit, then they must prepare their transactions by saving the state of the objects in permanent storage. This state is recorded as belonging to the top-level transaction of which it will form a part.
The two-phase commit protocol here may be performed in either a hierarchic manner or in a flat manner.
In the hierarchic two-phase commit protocol, the two-phase commit protocol becomes a multi-level nested protocol. The coordinator of the top-level transaction communicates with the coordinators of the subtransactions for which it is the immediate parent. It sends request for commit messages to each of the latter, which in turn pass them on to the coordinators of their child transactions. Each participant collects the replies from its descendants before replying to its parent. In our example, T sends commit request messages to the coordinator of T1 and then T1 sends the commit request messages to T12 asking about descendants of T1. The protocol does not include the coordinators of transactions such as T2, which has aborted.
In the flat two-phase commit protocol, the coordinator of the top-level transaction sends commit request messages to the coordinators of all of the subtransactions in the provisional commit list. In our example, to the coordinators of T1 and T12.

30. 3.3 Locking and Provisional Commits
Locks cannot be released after provisional commit.
Data items remain ‘protected’ until top-level transaction commits.
This may reduce concurrency.
Interactions between sibling subtransactions:
should they be prevented as they are different?
allowed as they are part of the same transaction?
Generally they are prevented.
Locks must be treated differently during a provisional commit in a subtransaction and the final commit issued by the root transaction. Locks cannot be released during a provisional commit because the whole transaction can still be aborted and intermediate states must not be exposed to concurrent transactions.
Therefore data items and resources of transactional servers must remain locked until the top-level transaction commits.
This reduces concurrency for obvious reasons (concurrent transactions cannot access the locked resources and may have to wait if they need them).
It is a matter of design of the transaction monitor, whether sibling subtransactions can access resources that a subtransaction has locked. The advantage would be that there are no 'unreal' concurrency control conflicts between sibling subtransactions, because they should be independent from each other and there is no reason to restrict access after a subtransaction has provisionally committed.
If interactions between sibling subtransactions are supported, however, different locking modes have to be defined and the whole concurrency control scheme has to be adjusted to nested transactions.
This is in general very complicated, which is why these types of interactions are not permitted in general.

31. 4 Distributed Transactions and Deadlocks
In distributed transactions, each server is responsible for applying concurrency control to its own objects, and all the servers jointly ensure the concurrent transactions are performed in a serially equivalent manner.
This means interleavings of two transactions have to be serially equivalent both locally at each server and globally.
Each server manages a set of objects and is responsible for ensuring that they remain consistent when accessed by concurrent transactions. Therefore, each server is responsible for applying concurrency control to its own objects. The members of a collection of servers of distributed transactions are jointly responsible for ensuring that they are performed in a serially equivalent manner.
This implies that if transaction T is before transaction U in their conflicting access to objects at one of the servers then they must be in that order at all of the servers whose objects are accessed in a conflicting manner by both T and U.

32. 4.1 Interleavings of Two TransactionsU
Write (A)
at X
Write (B)
at Y
Read (B)
at Y
Read (A)
at X
This slide shows an example where two transactions are not serial equivalent globally. Transaction T is before Transaction U in their conflicting access to Object A at Server X, but Transaction U is before Transaction T in their conflicting access to Object B at Server Y.
In this situation, deadlocks will occur as Transaction X will hold the lock for Object A at Server X, while Transaction U will hold the lock for Object B at Server Y, and they are waiting for each other to release the lock.
Transaction T before Transaction U on server X
Transaction U before Transaction T on server Y
This is not serially equivalent globally since T before U in one server and U before T in another.

33. 4.1 Interleavings of Transactions U, V and W
d.deposit(10)
lock D at Z
b.deposit(10)
lock B at Y
a.deposit(20)
lock A at X
c.deposit(30)
lock C
This figure shows another more complicated example regarding the interleavings of the transactions U, V and W involving the objects A and B managed by servers X and Y and objects C and D managed by server Z. at Z
b.withdraw(30)
wait at Y
c.withdraw(20)
wait at Z
a.withdraw(20)
wait at X

34. 4.2 Distributed Deadlock: Wait-For Graphs
Waits for
Waits
for
Held by
Held by B X Y Z W U V A C
The complete wait-for graph in (a) shows that a deadlock cycle object held by a transaction. As any transaction can only be waiting for one object at a time, objects can be left out wait-for graphs, as shown in (b).
Detection of a distributed deadlock requires a cycle to be found in the global transaction wait-for graph that is distributed among the servers that were involved in the transactions. Local wait-for graphs can be built by the lock manager at each server, while the global wait-for graph is held in part by each of the several servers involved. Communication between these servers is required to find cycles in the graph.
A simple solution is to use centralized deadlock detection, in which one server takes on the role of global deadlock detector. Each server sends the latest copy of its local wait-for graph to the global deadlock detector which checks for cycles in the global wait for graph.
Centralized deadlock detection suffers from the usual drawbacks on centralized systems: poor availability, lack of fault tolerance and no ability to scale.

35. 4.2 Local and Global Wait-For GraphsX T U Y V
local wait-for graph
global deadlock detector
A deadlock that is “detected” but is not really a deadlock is called a phantom deadlock. In distributed deadlock detection, information about wait-for relationships between transactions is transmitted from one server to another. If there is a deadlock, the necessary information will eventually be collected in one place and a cycle will be detected. As this procedure takes time, there is a chance that one of the transactions that holds a lock will meanwhile have released it, in which case the deadlock will no longer exist.
Consider the case of a global deadlock detector that receives local wait-for graphs fro servers X and Y. Suppose that transaction U the releases an object at server X and requests the one held by V at server Y. Suppose also that the global detector receives server Y’s local graph before server X’s. In this case, it would detect a cycle T  U  V  T, although the edge T  U no longer exists. This is an example of a phantom deadlock.
If transactions are using two-phase locking, they cannot release objects and then obtain more objects, and phantom deadlock cycle cannot occur.
Phantom deadlock: A deadlock that is “detected” but is not really a deadlock is called a phantom deadlock.
E.g.: Transaction U releases an object at server X and requests the one held by V at server Y. Assuming the latter is first received.

36. 4.3 Probes Transmitted to Detect DeadlockV
Held by W
Waits for
Waits
for
Deadlock
detected U C A B
Initiation Z Y X
A distributed approach to deadlock detection uses a technique called edge chasing or path pushing. In this approach, each of the servers involved has knowledge about some of its edges. The servers attempt to find cycles by forwarding messages called probes, which follow the edges of the graph throughout the distributed system. A probe message consists of transaction wait-for relationships representing a path in the global wait-for graph.
Each distributed transaction starts at a server (called the coordinator of the transaction) and moves to several other servers (called participants in the transaction), which can communicate with the coordinator.
Edge-chasing algorithms have three steps – initiation, detection and resolution.
Edge-chasing algorithm:
1. initiation
2. detection
3. resolution

37. 4.3 Two Probes Initiated ® ® ® ® ® ® T V U W ® ® ® ® ® ® T T V U W
(a) initial situation
(b) detection initiated at object requested by T
(c) detection initiated at object requested by W T
Waits for T
Waits for T T U W V T W V T U V U V U V T U W U T U W V
In the above algorithm, every transaction involved in a deadlock cycle can cause deadlock detection to be initiated. The effect of several transactions in a cycle initiating deadlock detection is that detection may happen at several different servers in the cycle with the result that more than on transaction in the cycle is aborted.
In order to ensure that only one transaction in a cycle is aborted, transactions are given priorities in such a way that all transactions are totally ordered. Timestamps for example, may be used as priorities. When a deadlock cycle is found, the transaction with the lowest priority is aborted. Even if several different servers detect the same cycle, they will all reach the same decision as to which transaction is to be aborted.
In this example, if the order is T → U → V → W then the transaction W will be aborted when either of these two cycles in (b) and in (c) are detected W
Waits
for W V
Waits W W
for

38. 5 Summary Transaction concepts: Two-phase commit
ACID properties
Transaction commands
Roles of distributed components in transactions
Two-phase commit
Phase one: voting
Phase two: completion
Distributed Transactions and Distributed Deadlocks
Distributed transactions and their interleavings
Distributed deadlocks and the detectors
Read Textbook Chapter 16.2, 16.3, and 17 (except 17.6).
In this topic, we have looked at transactions by means of which changes to shared resources can be made in a way that resources are protected against failures and integrity violations through concurrent updates.
We have explained the most important transaction concepts, which are the ACID properties (atomicity, consistency, isolation and durability), transaction commands or operations (begin, commit and abort) and the different roles that distributed components can play in transactions (transactional client, transactional server and transaction coordinator).
We have then looked at two-phase commit, the most prominent technique that is used to implement distributed transactions. The two phases of two-phase commit are a voting phase where all transactional servers notify the transaction coordinator whether they can commit their transaction. In the second phase, the coordinator would commit the transaction only if every single server voted in favour of committing. Otherwise the coordinator would send abort requests to the transactional servers.
We describe the operations of distributed transactions and the distributed deadlocks that may occur. We also examine the detection procedure for the distributed deadlocks. Read Textbook Chapter 16.2, 16.3, and 17 (except 17.6 which will be covered in the next lecture).