DISTRIBUTED TRANSACTION SERVICE,

NESTED TRANSACTIONS

&DESIGN PRINCIPLES

Distributed file systems having transaction facility need to support distributed transaction service.

A distributed transaction service is an extension of the conventional transaction service, which can support transaction involving files managed by more than one server.

When a transaction involves multiple servers, all the servers need to communicate with one another to coordinate their actions.

DISTRIBUTED TRANSCATION SERIVCE

During the processing of the transaction so as to achieve recoverability and concurrency control over the entire set of file operations in the transaction.

Distributed transaction would be to enforce that all client requests pass through a single server.

It is used in the XFDS file service.

Cont..

Distributed transaction service, a client begins a transaction by sending a begin_transaction request to any server.

The contacted server executes the being_transaction request and returns the resulting TID to the client.This server becomes the coordinator for the

transaction and is responsible for aborting or committing it and for adding other servers called workers.

Cont..

The request , add_transaction(TID, server_id of coordinator)

informs a server that it is involved in the TID.

It also make a call to the coordinator to inform it of its intention to join the transaction.

This information enables the coordinator and the workers of the transaction to coordinate with each other at commit time.

Cont..

In a distributed transaction, since the files changed within the transaction are stored on multiple servers, the commit protocol becomes more complicated.

A crash of one server does not normally affect other servers.

Hence the commit protocol must ensure that the transaction is not committed .

It is changes to the files are completed on some servers if to cannot be completed on all servers involved.

Two-Phase Multiserver Commit Protocol

The general protocol for committing distributed transactions has two phases.

The two-phase mulitserver commit protocol given in [Gray 1978].

When the client of a distributed transaction makes and end_transaction request.

The end_transaction operation is performed in two phases

(i) Preparation Phase (ii) Commitment Phase

Cont..

The Coordinator makes an entry in its log that it is starting the commit protocol.

It then sends a prepare message to all the workers telling them to prepare to commit. The message has a timeout value associated with it.

When a worker gets the message, it checks to see if it is ready to commit. If so, it makes an entry in its log and replies with a ready message.

Otherwise, it replies with an abort message.

(i) Preparation Phase:

If all the workers are ready to commit, the transaction is committed. For this, the coordinator makes an entry in its log indicating that the transaction has been committed.

It then sends a commit message to the workers asking them to commit. Otherwise is any of the replies was abort or the prepare message.

When a worker receives the commit message, it make a committed entry in its log and sends a committed reply to the coordinator.

(ii)Commitment Phase:

When the coordinator has received a committed reply from all the workers, the transaction is considered complete and all its records maintained by the coordinator are erased.

The coordinator keeps resending the commit message until it receives the committed reply from all the workers.

Cont..

Nested transactions are a generalization of traditional transactions in which a transaction may be composed of other transaction called subtransactions.

A subtranscation may in turn have its own subtransactions. Tree terminology is normally used in describing

relationships among the transactions belonging to the same family.

When a transaction starts, it consists of only one transaction called the top-level transaction.

NESTED TRANSACTIONS

When a transaction forks a subtransaction, it is called the parent of the subtransaction and the subtransaction and the subtransaction is referred to as its child.

The terms ancestors and descendants are also used.

A transaction is an ancestor and a descendant of itself.

Cont..

Nested- transcation system, a transaction many commit only after all its descendants have committed.

A transaction may abort at any time. Therefore, in order for an entire transaction family to

commit, its top-level transaction must wait for other transactions in the family to commit.

A subtransactions appears atomic to its parent.

Committing of Nested Transactions

If a failure occurs that causes a subtransation to abort before its completion.

All of its tentative updates are undone, and its parent is notified.

The parent may then choose to continue processing and try to complete its task using an alternative cause its ancestors to abort.

If failure cause an ancestor transaction to abort, the updates o fall its descendant transaction have to by undone.

Cont..

The following main advantages are:

It allows concurrency within a transaction. That is , a transaction may generate several subtransctions that run in parallel on different processors.

All children of a parent transaction are synchronized so that the parent transaction still exhibits serializability.

It provides greater protection against failures, in that it allows checkpoints to be established within a transaction.

Advantages of Nested Transactions

Based on his experience with the AFS and other distributed

file system, has stated the following general principles of designing distributed file systems,

(i)Clients have cycles to burn (ii)Cache whenever possible (iii)Exploit usage properties (iv)Minimize systemwide knowledge&change (v)Trust the fewest possible entities (vi)Batch if possible

DESIGN PRINCIPLES

It is always preferable to perform an operation on a client’s own machine rather than performing it on a server machine.

Hence cycles of a server machine are more precious than the cycles of client machines.

This principle aims at enhancing the scalability of the design.

Since it lessens the need to increase centralized resources and allows graceful degradation of system performance as the system grow in size.

(i)Clients have cycles to burn:

Better performance, scalability, user mobility, and site

autonomy motivate this principle. Caching of data at client’s site frequently improves overall system performance because it makes data available wherever it is being currently used. Thus saving a large amount of computing time and network bandwidth.

(ii)Cache whenever possible:

This principle says that, depending on usage properties ,files should be groped into a small number of easily identifiable classes.

Then class-specific properties should be exploited of independent optimization for improved performance.

(iii)Exploit usage properties:

This principle is aimed at enhancing the scalability of design.

The larger is a distributed system, the more difficult it is to be aware at all times of the entire state of the system and to update distributed or replicated a data structures in a consistent manner.

(iv) Minimize systemwide knowledge and change:

This principle is aimed enhancing the security of the system.

For example, it is much simpler to ensure security based on the integrity of the much smaller number of servers rather than trusting thousands of clients.

It is sufficient to only ensure the physical security of the servers and the software they run.

(v)Trust the fewest possible entities:

Batching often helps in improving performance greatly.

Similarly, transfer of data across the network in large chunks rather than as individual pages is much more efficient. The full file transfer protocol is an instance of the application of this principle.

(vi)Batch if possible:

THANK YOU