CloudTPS: Scalable Transactions for Web Applications in the Cloud

ABSTRACT

NoSQL Cloud data stores provide scalability and high availability properties for web applications, but at the same time they sacrifice data consistency. However, many applications cannot afford any data inconsistency. CloudTPS is a scalable transaction manager which guarantees full ACID properties for multi-item transactions issued by Web applications, even in the presence of server failures and network partitions. We implement this approach on top of the two main families of scalable data layers: Bigtable and SimpleDB.

Existing System

The scalability and high availability properties of Cloud platforms however come at a cost.

1) First, these scalable database services allow data query only by primary key rather than supporting secondary-key or join queries.

2)Second, these services provide only weak consistency such as eventual data consistency: any data update becomes visible after a finite but undeterministic amount of time.

As weak as this consistency property may seem, it does allow to build a wide range of useful applications, as demonstrated by the commercial success of Cloud computing platforms. However, many other applications such as payment and online auction services cannot afford any data inconsistency. While primarykey- only data access is a relatively minor inconvenience that can often be accommodated by good data structures, it is essential to provide transactional data consistency to support the applications that need it.

Proposed System

A transaction is a set of queries to be executed atomically on a single consistent view of a database. The main challenge to support transactional guarantees in a cloud computing environment is to provide the ACID properties of Atomicity, Consistency, Isolation and Durability without compromising the scalability properties of the cloud. However, the underlying cloud data storage services provide only

eventual consistency. We address this discrepancy by creating a secondary temporary copy of the application data in the transaction managers that handle consistency.

Advantage:

CloudTPS exploits three properties typical of Web applications to allow efficient and scalable operations. First, we observe that in Web applications, all transactions are short-lived because each transaction is encapsulated in the processing of a particular request from a user. This rules out long-lived transactions that make scalable transactional systems so difficult to design, even in medium-scale environments. Second, Web applications tend to issue transactions that span a relatively small number of well-identified data items. This means that the commit protocol for any given transaction can be confined to a relatively small number of servers holding the accessed data items. It also implies a low (although not negligible) number of conflicts between multiple transactions concurrently trying to read/write the same data items. Third, many read-only queries of Web applications can produce useful results by accessing an older yet consistent version of data

IMPLEMENTATION

Implementation is the stage of the project when the theoretical design is turned out into a working system. Thus it can be considered to be the most critical stage in achieving a successful new system and in giving the user, confidence that the new system will work and be effective.

The implementation stage involves careful planning, investigation of the existing system and it’s constraints on implementation, designing of methods to achieve changeover and evaluation of changeover methods.

Main Modules:-

Modules:

1. Atomicity:

The Atomicity property requires that either all operations of a transaction complete successfully, or none of them does. To ensure Atomicity, for each transaction issued, CloudTPS performs two-phase commit (2PC) across all the LTMs responsible for the data items accessed. As soon as an agreement to “COMMIT” is reached, the transaction coordinator can simultaneously return the result to the web application and complete the second phase .

2. Consistency:

The Consistency property requires that a transaction, which executes on a database that is internally consistent, will leave the database in an internally consistent state. Consistency is typically expressed as a set of declarative integrity constraints.We assume that the consistency rule is applied within the logic of transactions. Therefore, the Consistency property is satisfied as long as all transactions are executed correctly.

3. Isolation:

The Isolation property requires that the behavior of a transaction is not disturbed by the presence of other transactions that may be accessing the same data items concurrently. The TPS decomposes a transaction into a number of sub-transactions, each accessing a single data item. Thus the Isolation property requires that if two transactions conflict on any number of data items, all their conflicting sub-transactions must be executed sequentially, even though the sub-transactions are executed in multiple LTMs.

4. Durability:

The Durability property requires that the effects of committed transactions cannot be undone and would survive server failures. In our case, it means that all the data updates of committed transactions must be successfully written back to the backend cloud storage service.

System Specification:

Hardware System Requirement

Processor - Pentium –III

Speed - 1.1 Ghz

RAM - 256 MB(min)

Hard Disk - 20 GB

Floppy Drive - 1.44 MB

Key Board - Standard Windows Keyboard

Mouse - Two or Three Button Mouse

Monitor - SVGA

S/W System Requirement

Operating System : Windows 95/98/2000/NT4.0.

Application Server : Tomcat6.0

Front End : HTML, Java.

Scripts : JavaScript.

Server side Script : Java Server Pages.

Database : Mysql.

Database Connectivity : JDBC.