A transaction management in cloud database : proposal model

A transaction management in cloud database : proposal model

Ms.Vian F. a, Dr. Ziyad Tarik Abdulmehdi

b

" Foundation Department , IT Instructor of Bayan college , Muscat , Oman"

" Information technology and computer science,Ass.Pro.& Hod of Mazoon college,

muscat ,Oman"

Abstract

Cloud computing, this new technique contributed to attract many users by the services

that provided to uses of the cloud. One of these services is cloud database, which

means the user of the cloud can create a database through the application which cloud

is provided and store it at the cloud so this database called cloud database.

Now to run the data at cloud database needs to use a specific transaction management

that provide data consistency because transaction management executing the ACID

So to use the traditional transaction management technique in cloud case is not a

proper choice because it is not simple to follow. And there is another reason is the

weakness in data consistency that many web applications cannot afford it. As well the

modifying of the data items that occur only in one site host (SH) , large number of

aborted transaction and the longtime of execution the transaction lead to search for

transaction management that solve all these issues.

So the concept of the proposal model that presented through this research is to find a

transaction model can be executed at base station (BS)and site host (SH), namely the

proposal model can modify the data item locally and then pre-commit , when SH

connects with BS these pre-committed transaction are sent to the BS and re-executed

on the master data at BS as a base transaction (BT)(S ).

At SHS the transactions are pre-committed according to the availability of the data

items , because each SH can obtain a specific amount of the value δi and the rest is

kept at BS , this process maintain the data consistency.

The modifying of the data items at SH is allowed in case ,the request transaction is

within the limit of δi . If it is not SH is going to block the transaction and send it to

the BS as a request transaction to executed there.

The result of the implanting this proposal model is positive.

CHAPTER ONE

INTRODUCTION

1.1 Background

The advance in network communication technology especially in "Internet" that

causes to emerge the cloud computing .This new technology contributed in easing the

process of the data access from anywhere and at any time .But there is one issue is

concerning all is the longevity of the connection between site host and base station.

That means the possibility to keep the connection between them without

disconnection is impossible because the disconnection occur due to different reasons

and maybe in the middle of the transaction. Consequently most of the transaction

models have the same aim that how to achieve the consistency for cloud database

because many application cannot afford the un consistency in data. Therefore one of

these models is Kangaroo transaction (KT) model. This model base on the Base

Station (BS) and Site Host (SH). Kangaroo transaction is consist of two modes, split

mode and compensate mode .So the transaction between BS and SH that include

Atomicity, Consistency and durability

1.2 Data Replication

According to (T.Ho;D.Abramson,2005;H.Lin;J.H.Abawajy; R.Kumar B;

R.Brennan;G.O'Gorman;C.Doherty;N.Hurley;C.McArdle,2006)"Data replication is

the operation of producing many copies for the same data file , and distributed these

copies (replicas)among sites according to some techniques called Replication

Strategy".

Replication management contributed in increasing the availability and reliability for

the user and also decreases the response time and the consumption of the bandwidth,

but in another side replication also contributed in increasing the cost of the storage

space.

Consequently, research can say that replication management can provide a high data

availability, fault tolerance and enhance the implementation (Zhou, Goscinki, 1999).

There are two type of replication management:

i. Synchronous replication.

ii. Asynchronous replication.

Synchronous replication: In this replication the move or the update together occurs at

the same speed and time, this mean that synchronous can provide a tight consistency

between store's data and cause the latency between data consistency is zero.

Asynchronous replication: This type of replication provide a loose consistency

between store's data this cause the latency greater than zero (Ziyad, 2006).

1.3 Problem Statement

Through the research in cloud database domain, found many researches and studies

have been done in database management transaction and all of them have one

common aim is to find a proper model that ensure the consistency which is one of the

ACID properties.

The Kangaroo transaction model one of the models that deals with transaction so we

can define the transaction is a set of database operation.

Kangaroo transaction model based on the transaction between the base station (BS)

in cloud and Site Host(SH) which connected with BS via net (S.Flower,2012).

So the concept of this model is a global transaction (Kangaroo transaction (KT)).This

transaction issued by the user of internet. KT is consisting of set of Joey transactions

JT which executed at BS (A.Helal; S.Balakrishnan; M.Dunham; R, Elmasri, 1996).

Hence Kangaroo transaction (Dunham et al, 1997; Dunham and Kumar, 1999; Turker

and Zini, 2003) consist of two modes for processing a KT

i. Compensating Mode

ii. Split Mode

In compensating mode: - the abortion of the JT causes to stop KT entirely. But by

executing the compensating transaction can preserve the Atomicity, but in another

side it breaks the Consistency and Durability.

In split mode: - the abortion of the JT required terminating KT, but still committing

the previous JT. This means the current sub transaction is committed or aborted

normally upon the DBMS's decision, consequently this mode break the Atomicity and

consistency.

From the above we can evolve that both of them couldn't ensure the Serializability

(Ziyad, 2006).

Transaction

Management Model

Problems of the Model

Kangaroo

Break the consistency and Durability of the transaction in

compensating mode.

Break Atomicity in Split mode.

Table1.1: Weakness of the Transaction Model

The research on the Kangaroo Transaction model discovers two types of weaknesses

that can note them in Table 1.1, which they need to be solved.

The primarily concerned issues include,

i. Only one site host (SH) is allowed to update the data item

ii. Large number of aborted transactions.

iii. A long time of execution transactions at site host (SH).

2.1 Introduction

Cloud database is emerging to provide database service over the Internet . In cloud –

based environment , data are distributed at internet scale and system needs to handle a

huge number of user queries simultaneously without delay (T. Wang , 2010).

Transaction is a set of queries to be executed automatically on a single consistent

view of database . The main challenge to support transactional guarantees in 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 problem by creating secondary temporary copy of the

application data in the transaction managers that handle consistency (Z.Wei; G. / L.

Pierre, 2010).

Generally, cloud database has following features. Fast response and high efficiency in

serving queries are guaranteed important, load balancing should be maintained

through reasonable data distribution, and thus favorable system performance can be

guaranteed (T. Wang, 2010).

i. The system can provide high manageability and availability

with the ever changing query patterns (T. Wang, 2010).

ii. The topology of database is dynamic , that mean the database nodes

could be added or deleted over period time (T. Wang, 2010).

2.2 Cloud Computing Architecture

Cloud computing consist of two parts:-

i. Base station(BS):-

Is web site from many numbers of web sites distributed in cloud

provide diver types of services to the users of the cloud of

course according to their demands, each BS has a data centers

distributed in different countries to maintain the master data.

BS can connect with SH(S) through the ISP (Internet Service Provider)

by a wireless connection.

ii. Site Host (SH)(S):-

Site host refers to PC (personal computer) , Laptop , Smart phone

and I pad .SH(s) is connect with BS wirelessly through ISP as well as SH

can move between ISP(S) , SH is disconnected by BS and reconnected at

any time and from any ISP also SH has a different application to connect

with BS. SH can connect with only one BS that led to limited resources.

2.4 Cloud Computing Transaction

A transaction submitted from a SH to BS is called Site transaction ST . SH can issues

transaction and receives the result from the BS . For instance , a user asks for Royal

Opera House (ROH) ticket time table through their SHS and the answer will be sent

to them . Because of the characteristics of cloud environment , ST has several

additional requirements:-

BS

SH1 SH2

Data center

Base Station

Cloud

Site Host

Wireless connection

Figure 2.1 Cloud Data Base Environment

i Due to SH has less processing capacity as BS , ST should be able to

split into sets of smaller transaction . These shorter sub – transaction

can execute on BS If possible , most of the computation on the SH

should be shifted to BS for processing .

When computing tasks are moving to BS , the BS have more

computing power and shorter processing time . In addition , the

computing resources are closer in BS .

ii ST has a large time execution . Because of the communication

overhead and frequent disconnection , the time required for

exchanging needed data between SH and BS is longer . Apart from

this , SH has slower execution speed therefore the same transaction

on SH will require larger execution time than on the BS.

iii ST should be executable when SH is in cloud and disconnected from

the computing resources .It is not possible for SH staying connected all

the time with data resources .After needed data has been caching into

in to cloud storage device then SH can operate in autonomous mode.

Data inconsistency for a period of time should be allowed .When the

connection is established the new data item will be updated to the main

database .

iv STS require being able to operate in distribution heterogeneous

environment . Different types of SH cooperate in mobile environment

and different data base systems are accessed during implementing state

of ST . Cloud application should take in account the representation of

data format in different systems.

ST is more difficult than ordinary transaction in both the design and execution .

When SH moves from one ISP to another ISP , many computing processes like

established new communication channel , data managing and forward the status of

transaction to a new BS involving the execution of ST not normally unpredictable in

time but also depends on their location .

Some of the models developed in the ordinary transaction such as two phases commit

(2PC) protocol and caching mechanism need to be extended or modified to be able to

apply in the ST and also should consider how to reduce a long time execution and

avoiding the abortion of the transaction .Another issue is how to increase SH to more

than one and caching the data item in order to increase the autonomy of the

SH.(Ziyad,2006)

.5.1 Architecture

The architecture of the cloud computing consist of two section Front –end and

Back – end and they connect with each other through network that’s usually via

Internet . Front – end is the side of the cloud’s user . This side is consist of

client’s computer or A network of computers and the application that is required

to access the cloud. Back- end side of cloud consists of various computers ,

servers and data storages . Central server administers the system, monitoring

traffic and client requests . To ensure that everything run smoothly, it should

follow a set of rules called protocols (S. Jonthan , 2008).

In our proposal model ,the transaction executed on SH possibly if the SH

provides some minimal capabilities .The data which stored at SHS (memory /

disk ) generally come from database servers . Therefore , SH's work should

remain consistent with the database servers. Cloud's clients may varying from

thin clients to full clients , rely on their characteristics as follows:

i. Thin client architecture:

In this type clients need to run operations at the servers and

this type is suitable for dumb terminals or small PDA

applications .Thin client has limited resources such as ( small

screen size , small cache memory , limited width). In this

architecture server is responsible of all operation whereas

client just preview text , graphics, etc. (Ziyad,2006).

ii. Full client architecture:

In cloud environment ,clients can be forced to work in

disconnected mode or with a weak connections (due to

low bandwidth , high latency or high costs) in this architecture

full clients beat the server because they have ability to execute

the application without need to connect directly to the remote

servers. Full clients are usually portable computers with enough

resources to implement the application (Ziyad,2006).

iii. Flexible client- server architecture

This architecture generalizes the approaches of thin and full

client . The roles of client , server and the application

functionalities are dynamically relocated .The distinct between

client and server maybe blurred for the purpose of performance

and availability.(Ziyad,2006)

iv Client – agent – server architecture (Surrogate object model of

transaction architecture)

this architecture called third tier model .In this architecture each

site host SH has a surrogate object SO and surrogate support site

SSS and this SSS contain a group of SOS for all the respective

SHS . In this architecture client send the request transaction to the

SSS instead to database server . SSS receives the request from

client and forward it to the SO. All SH , SO , SSS , FH considered

to be part of cloud( R. Shanmugam , M.A. Maluk Mohamed and S.

Nazreen, 2012) .