Running head: ACID PROPERTIES, CAP THEOREM & MOBILE DATABASES 1

Acid Properties, CAP Theorem & Mobile Databases

Ajayi Rosiji

CS828-1501C-01: Advanced Topics in Database Systems

Colorado Technical University

February 2, 2015
ACID PROPERTIES, CAP THEOREM & MOBILE DATABASES 2

Connolly & Begg (2014) describes the four properties that all database transactions

should possess using the acronym ACID which stands for: atomicity, consistency, isolation and

durability. (pg. 623) Atomicity is the “all or nothing” property that ensures that a transaction is

an indivisible unit that is either performed in its entirety or not performed at all. Consistency is

the property that ensures that a transaction transform the database from one consistent state to

another. Isolation property ensures that transactions execute independently of one another. The

durability property ensures that the effects of a successfully completed (committed) transaction

are permanently recorded in a database and must not be lost due to subsequent system failures.

Connolly & Begg (2014) posits that due to the transient nature of mobile devices also

known as mobile hosts (MH), the ability to enforce the ACID properties of databases becomes

more cumbersome. MH continues to move from one mobile support station to another. A mobile

support station manages the mobile hosts within its cell. When a MH moves from one mobile

support station to another, a transfer of control is passed from one mobile station to another.

Connolly et al. (2014) provides a list of issues with mobile databases which are listed below:

 Bandwidth is low with wireless communication

 There are many areas where wireless connectivity is not available

 Wireless connectivity may be unreliable when mobile hosts continually move

around.

 It is very expensive to transfer data over a wireless Wide Area Network

 Security may be an issue in cases where mobile devices is stolen

 Large number of mobile users will cause higher server workloads

 Mobile hosts are not stationary and move from between cells

 Retrieval of data is much slower than if data is stored locally on mobile host.
ACID PROPERTIES, CAP THEOREM & MOBILE DATABASES 3

The CAP theorem was proposed by Eric Brewer in 2000. The theorem states that a

distributed system cannot simultaneously provide all the desirable properties of consistency,

availability and partition tolerance. According to CAP theorem, consistency refers to the ability

for all nodes to see the same data at the same time. Availability refer to the guarantee that all

reads and writes are always successful and partition tolerance refers to the guarantee that the

CAP properties of the system are maintained even in the event of network that prevents some

machines or computers to communicate with one another. (https://foundationdb.com/key-value-

store/white-papers/the-cap-theorem)

According to Brewer (2012), the idea of “2 of 3” is misleading in the sense that

researchers and database designers are forced with the option to give up either consistency or

availability in the presence of network partitions. With the increasing need of mobile databases

that are partitioned by network segments, more flexibility in the design can help guarantee highly

available and consistent databases amidst network partitions. My proposed transaction

processing model for mobile databases using the CAP theorem is the Fault-Tolerant Transaction

Processing Model (FTTPM) for mobile databases. FTTPM seeks to guarantee high availability

and consistency in the presence of network partitions through the use of fault tolerant design by

enlisting coordination servers. Without the use of these coordination servers, the database system

will be forced to choose between availability and consistency. Let’s take for example a

partitioned network with two nodes A and B. Allowing only A to update will cause the nodes to

become inconsistent, hence forfeiting consistency. Likewise, if the choice is to preserve

consistency, allowing B to always appear as available forfeits the property of availability as A is

not available. Only when nodes A and B communicate can both availability and consistency be

achieved, thereby forfeiting the network partition. (Brewer, 2012)

The goal of the Fault-Tolerant Transaction Processing Model (FTTPM) is to ensure that

even if some machines are down or not able to communicate over the network, the database and

applications connected to it remains up. The coordination servers use the Paxos algorithm to

maintain a small amount of shared state that itself is Consistent and Partition-tolerant. Like the

database as a whole, the shared state is not available but is available for reads and writes in the

partition containing a majority of the coordination servers. FTTPM uses this shared state to

maintain and update a replication topology. When a failure occurs, the coordination servers are

used to change the replication topology. The coordination servers are not involved at all in

committing transactions. (https://foundationdb.com/key-value-store/white-papers/the-cap-

theorem)

A simple configuration of the FTTPM is shown below:

Figure 1. Maintenance of availability during partition. Retrieved from

https://foundationdb.com/key-value-store/white-papers/the-cap-theorem

In the above example, when partition A rejoins the network with its coordination servers, it will

receive transactions that occurred in its absence, or in the worst case, transferring the content of

the database and all machines will be able to accept transactions in a fault tolerant manner.
ACID PROPERTIES, CAP THEOREM & MOBILE DATABASES 5

The trade-off in the FTTPM design is consistency as the model tries to ensure that all

databases will be updated when network connection is restored. However, it is worth knowing

that both availability and consistency is optimized using this model as each partitions continue to

allow for read and write to the coordination servers which serves a temporary storage until

network partition or connectivity is restored. Once network connectivity is restored, FTTPM uses

the Paxos algorithm to coordinate data replication between different nodes, while the database

management system manages the concurrency control and data updates to the databases.

The CAP theorem is very significant in today’s society where goods and services are

readily available over the internet. Several millions of people are buying and selling things

online using mobile devices and wireless connections. Several merchants today are receiving

payments through smart devices attached to their laptops or tablets using wireless connections.

Let’s take into consideration a user who tries to buy an item on a website and gets an error:

“HTTP 500 java.lang.schrodinger.purchasingerror.” The user is now faced with the dilemma of

having paid for something s/he won’t get, or has not paid at all or may be the error is immaterial

to the transaction. The user will probably not visit the site again and might even be prompted to

call his or her bank to block payment on the transaction. (Browne, 2009) According to Viraf

(2008), states that “If a broker’s electronic trading platform is 5 milliseconds behind the

competition, it could lose at least 1% of its flow; that’s $4 million in revenues per millisecond.

Up to 10 milliseconds of latency could result in a 10% drop in revenues. From there it gets

worse. If a broker is 100 milliseconds slower than the fastest broker, it may as well shut down its

FIX engine and become a floor broker.”

Conclusively, as mobile databases become more popular in business transactions and are

being implemented in different geographical locations around the world, it is impossible to avoid

network partitioning in distributed database management systems. It is very important that

database designers come up with new and effective transaction processing models that optimize

availability and consistency even in the face of increasing network partitioning.

References:

Brewer, E. (2012). CAP twelve years later: How the" rules" have changed. Computer, 45(2), 23-

29.

Browne, J. (2009). Brewer's CAP Theorem: The Kool aid Amazon and EBay have been

drinking. Retrieved from: http://www.julianbrowne.com/article/viewer/brewers-cap-

theorem

Connolly, T. M., & Begg, C. E. (2014). Database Systems: A Practical Approach to Design,

Implementation and Management. New Jersey, NJ: Pearson.

FoundationDB. (2015). The CAP Theorem. Retrieved from: https://foundationdb.com/key-value-

store/white-papers/the-cap-theorem

Viraf, W. (2008). The Value of a Millisecond: Finding the Optimal Speed of a Trading

Infrastructure. Retrieved from: http://www.tabbgroup.com/PublicationDetail.aspx?

PublicationID=346