Airline reservation system using concurrency control computer science

Since it is impossible to cover all aspects o f concurrency control as well as its mechanisms, this paper focuses on investigating four transaction isolation levels: read uncommitted, re

Airline Reservation System using

Concurrency Control

Graduation Thesis Submitted to

Hanoi University

for the degree of

Bachelor o f Computer Science

Doing business on the Internet can be considered as a crucial source o f profit When transactions are performed online, the possibility o f concurrent, competing transactions is increased Thus, how to ensure such events do not violate the data integrity

o f a database system is one important question that needs to be solved when designing a commercial system Concurrency control is known as one key mechanism to deal with this problem Knowing its importance, this project aims to provide a sufficient knowledge base o f concurrency control and related issues Since it is impossible to cover all aspects

o f concurrency control as well as its mechanisms, this paper focuses on investigating four transaction isolation levels: read uncommitted, read committed, repeatable read and serializable by building an airline reservation system for demonstration Although two months is a short time, this project ends with several surprising findings about highest level o f transaction isolation - serializable 一 in the MySQL open source DBMS

A ck n o w led g m en ts

I would like to thank my dear Instructor Mrs Marry Gallagher for her guidance and enthusiasm Without her detailed suggestions and encouragement, I never would have taken on this project

I also thank Faculty o f Information Technology in Hanoi University that gives me

a great chance to undertake this project

Finally, I am grateful to my family, friends for their supports and encouragement

Ta Thi Hong December 2009

Table of Contents

Table o f Contents iv

List o f fig u re s vi

Chapter 1 Introduction 1

Objectives 1

M otivation 2

Methodology 3

An Overview o f the Rest o f the Document 4

Chapter 2 Background Knowledge 5

Concurrency control definition 5

Transactions and AC ID properties 7

Schedules 9

Serial schedules 10

Serializable schedules 11

Transaction Isolation 12

READ UNCO M M ITTED 13

READ C O M M IT T E D 14

REPEATABLE R E A D 14

S E R IA L IZ A B L E 15

Chapter 3 Airline reservation system 20

Database design 20

Data objects and classes 22

Reservation Process 25

User interface 2ö Concurrency 28

Chapter 4 Investigating isolation levels in airline reservation system 33

Remarkable problems in building the demo system 33

Four isolation levels in airline reservation system 34

Read Uncommitted isolation level 36

Read committed isolation level 37

Repeatable read isolation level 39

Serializable isolation level 41

Chapter 5 Summary and Conclusions 48

References 50

Appendix 1 Application Code 51

PHP C ode 51

List of Figures

Figure 1 : Two transactions 10

Figure 2: Serial schedule in which T ịprecedes Tl. 11

Figure 3: T ị and 72 interleaves 11

Figure 4: D irty read 17

Figure 5: Non-repeatable read 18

Figure 6: Phantom reads 19

Figure 7: ER diagram 21

Figure 8: Flight table 21

Figure 9: Customer table 21

Figure 10: Reservation table 22

Figure 11: Table relationship 22

Figure 12: List o f available flights 27

Figure 13: Check availability 27

Figure 14: Personal information form 27

Figure 15: Confirm ation 28

Figure 16: Flow chart 29

Figure 17: Check availability code 30

Figure 18: Code handles submit action 31

Figure 19: Code handles commit or rollback action 32

Figure 20: Customer reservation 35

Figure 21 : First test scenario Figure 22: Serializable tes scenario

Chapter 1 Introduction

Objectives

In the age o f information systems, where everything is shared on the Internet, people all over the world are connected together via an international channel Therefore, more and more businesses, services, social networks etc are taking advantage o f this trend Every day, there are hundreds o f millions o f people doing business on-line When transactions are performed on-line, the chance that two or more people w ill want the same product at the same time is inevitable It is a critical problem especially when it relates to money In term o f database management systems (DBMS), there is a

mechanism to deal with this issue: concurrcncy control Since ¡I is important in designing

a database system, the initial objective o f this paper is to provide a better understanding about concurrency control and its effect on a database management system Building a simple airline reservation system as a demonstration system to investigate differencesamong isolation levels o f transactions is another main objective o f this project

M otivation

Among many interesting topics about computer science, I decided to choose topic

uairline reservation system using concurrency согПгоГ for my graduation thesis for the following reasons:

First concurrency control o f transactions is a problem that must be considered in the design o f most commercial systems The accuracy and consistency o f data always are two important properties in a database management system However, when two or more transactions are performed simultaneously (especially when both try to update the same data at the same time), these two properties are more likely to be broken With concurrency control, the occurance o f inconsistent data is lower

Unfortunately, in most undergraduate courses, concurrency control is not a subject covered in depth A t university, there are many subjects about programming languages, database management system, data structure algorithm or information system etc With this knowledge, a student can have an overall picture o f a system but this is not sufficient In case o f a real commercial system, there are many issues that need to be concerned and concurrency control is one o f them Thus, learning concurrency control o f transactions would help an undergraduate student have a better knowledge o f database management systems

Lastly but most importantly, working in database field always brings me lot o f excitement Despite o f its hardness, database management system is an interesting subject In addition, since concurrency control is an important technique in database technologies, seizing the essence o f this matter is a competitive advantage for me in future jobs

o f concurrency control.

To get a real understanding o f this issue, I decided to build an airline reservationsystem in which I would try to apply the concurrency control theory Here is theenvironment for this demo system

- OS environment: Windows

- Database server: MySQL version 5.1 or higher

- Apache Web Server: Xampp version 1.7.2

- Web browsers: Firefox, Chrome, Internet Explorer (two browsers are

required)

- Programming language: PHP

By building a demo system, the problem w ill be visualized, easy to understand and it is the best way to demonstrate the effect o f concurrency control on a database management system

3

An Overview of the Rest of the Document

This paper includes the following main parts

Chapter 2: Background Knowledge This chapter provides a summary o f knowledge needed for this project Definitions o f concurrency control and related terms are presented Examples and related issues are discussed to ensure that readers could go through the content o f this paper without difficulties

C hapter 3: Airline reservation system This chapter describes the design as well

as the structure o f the airline reservation system A ll classes and their functions are explained to provide better understanding o f system implementation

Chapter 4: Investigating isolation levels in airline reservation system This

chapter describes the process o f applying transaction isolation levels in the demo system Test results are discussed to provide reader a clearer view o f differences among four levels o f transaction isolation levels This chapter ends with a summary o f findings

Chapter 2 Background Knowledge

Concurrency control definition

Most Database Management Systems (DBMS) run in a multiuser environment, with the expectation that users w ill be able to share the data contained in the database In applications like Web services, banking, or airline reservations, hundreds o f operations per second may be performed on the database I f users are only reading data, no data integrity problems w ill be encountered, because no changes w ill be made in the database However, i f one or more users are updating data, then potential problems with maintaining data integrity arise When more than one transaction is being processed in a database at the same time, the transactions are considered to he concurrent, interactions among concurrently executing transactions can cause the database state to become inconsistent, even when the transactions individually preserve correctness o f the state and there is no system failure In a database management system, concurrency control is a mechanism that “ensures that concurrent transactions are performed correctly without violating the data integrity o f the database” (Wikipedia 2009b)

A full definition o f concurrency control is “The process o f managing simulìaneous operations against a database so that data integrity is maintained and the operations do not interfere with each other in a multiuser enviroriment ’’ (Hoffer, Prescott

& McFadden 2004, p 471)

5

There are two basic mechanisms used for concurrency control They areoptimistic and pessimistic.

Optimistic: This mechanism assumes that although conflicts are possible, they

w ill be very unlikely Therefore, it is not necessary to lock1 every record every time it is used The system w ill allow multiple users to simultaneously access a shared database and perform their transactions However, i f two users actually do try to update the same record at the same time, then one user’s updates are aborted Optimistic concurrency control is called “ optimistic,，because the system assumes the best case - it assumes that there would not exist two users who want to update the same record at the same time

Pessimistic: This mechanism is also known as 'locking" Locks allow multiple users to safely share a database as long as all users are updating different data at the same time When locks are used, it is impossible for two users to update a row at the same time As soon as one user gets a lock, no one else can process that row This is a safe, conceptually simple approach The disadvantage is that it requires overhead for every operation, whether or not two or more users are actually trying to access the same record Furthermore, every time that a user tries to access a row, the system must also check whether the requested row(s) are already locked by another user or not Pessimistic concurrency control is called "pessimistic" because the system assumes the worst — it assumes that two users w ill usually want to update the same record at the same time, and then prevents that possibility by locking records, no matter how unlikely conflicts actually are (IB M 2009)

1 A lo c k is a mechanism fo r lim itin g other users’ access to a piece o f data When one user has a lock on a record，the lock prevents other users from changing (and in some cases reading) that record.

When you use optimistic locking, you do not find out there is a conflict until justbefore you write the updated data In pessimistic locking, you find out there is a conflict

as soon as you try to read the data In the SQL Guide on the IBM website，the writer has

an interesting example o f optimistic and pessimistic locking He considers a bank as a database system and bank’ s customers as system’ s users In this case, he calls pessimistic concurrency control like "having a guard at the bank door who checks your account number when you tiy to enter I f someone else is already in the bank accessing your account, then you cannot enter until that other person finishes her transactiori and leaves” (IB M 2009) Optimistic concurrency control, on the other hand, "allows you to walk into the bank at any time arid try to do your business, but at the risk that as you are walking out the door the bank guard will tell you that your transaction conflicted with someone else’s and yo u ’ll have to go back and do the transaction again” (IB M 2009)

Optimistic and pessimistic concurrency control differ in another important way besides the time at which conflicts are detected and error messages are issued The pessimistic mechanism allows one user to not only block another user from updating the same record, but even from reading that record With the optimistic mechanism, however,

we do not check for conflicts except at the time that we write updated data to the database

Transactions and ACID properties

To have a clear understanding o f concurrency control, we first need to understand

transactions. Informally, a transaction is a collection o f one or more operations on the database that must be executed atomically; that is either all operations are performed or

7

none are When processing a transaction the DBMS must ensure that an executed transaction should follow ACID properties which are: atomicity, consistency, isolation and durability.

Atom icity: The ability o f a DBMS to tk guarantee that either all o f the tasks o f a transactiOfi are performed or none o f them ¡S” (Wikipedia 2009a) I f and only i f all parts

o f the transaction succeed, the whole transaction w ill be committed and written in the database Otherwise, the whole transaction w ill be rolled back and none o f the tasks is written For example, suppose that the program accepts a new customer order, increases Balance Due, and stores the updated Customer record However, suppose that the new Order record is not inserted successftilly for some reason In this case, we want none o f the parts o f the transaction to affect the database

Consistency: The ability o f a DBMS to “ensure that the database remains in a consistent state before the start o f a transaction and after the transaction is over (whether

it is successful or notj” (Wikipedia 2009a) It states that only valid data w ill be written to

the database If, for some reason, an executed transaction violates the database’s consistency rules, the entire transaction w ill be rolled back and the database w ill be restored to a state consistent with those rules For example, i f the inventory on-hand balance must be the difference between total receipts minus total issues, this w ill be true both before and after an order transaction, which depletes on-hand balance to satisfy the order

Isolation: The ability o f a DBMS to ensure that other operations cannot access or see the data in an intermediate state during a transaction or changes to the database are not revealed to users until the transaction is committed This constraint is required to

maintain the performance as well as the consistency between transactions in the DBMS Thus, each transaction is unaware o f other transactions executing concurrently in the system For example, this property means that other users do not know what the new inventory on-hand is until an inventory transaction is complete; this property then usually means that other users are prohibited from simultaneously updating and possibly even reading data that are in the process o f being updated.

Durability: The ability o f a DBMS to "guarantee that once the user has been notified o f success, the transaction will persist, and not be urtdorie" (Wikipedia 2009a) Thus, i f a transaction is committed, no subsequent failure o f the database can reverse the effect o f the transaction Durability does not imply a permanent state o f the database Another transaction may overwrite any changes made by the current transaction without obstructing durability

Among all o f these transaction properties, providing isolation is the main goal o f concurrency control Thus, in this paper, we are going to focus on examining isolation levels in term o f concurrency control

9

Example 1: Assume that there are two transactions Tj and 丁2 and their actions are

Figure 1: Two transactions

A and В are database elements that can be accessed by Ti or T2 whereas t and s

are local variables o f Ti and 丁2 In this example the only consistency constraint is that the

value in A must equal the value in в when the transaction starts and when it completes According to the above figure, transaction Tj adds 50 to both A and в；T2 multiplies both

A and В by 2 I f these transactions run separately, i.e in isolation, the database remains

E xam ple 2: There are two serial schedules for the transactions o f Figure 2，one is

that T ịprecedes T2 and the other is vise versa Figure 2 shows the schedule in which Tj

precedes T2 and the initial state is A=B=20

As shown in Figure 3，at the end o f the transactions, the value o f A is 140 while the value o f в is only 90 A t this time, the constraint A=B is violated In other words, this schedule leads to inconsistent results.

We say that concurrent transactions need to be processed “ in isolation., so that they do not interfere with each other Procedures that process transactions so that the outcome is the same as this are called serializable Processing transactions using a serializable schedule w ill give the same results as i f the transactions had been processed one after the other Schedules are designed so that transactions that w ill not interfere with each other can still be run in parallel

Transaction Isolation

One solution for the problems o f interleaving between concurrent transactions is grouping execution statements into transactions Recall from the “ Transactions and ACID properties” part, a transaction is a set o f operations that must be executed together or

none is A transaction can be started by using the SQL command “start transaction” An

executing transaction only ends when it executes a “ com m ỉt” or a “ rollback” statement With the “ commit， statement, all changes made by the transaction are written

successfully in the database On the other hand, i f a transaction ends with the statement

“ rollback” the changes made by that transaction w ill be aborted

MySQL implements transaction isolation levels to give clients control over what kind o f changes made by other transactions they w ill be able to see Different isolation levels allow or prevent the various problems that can occur when different transactions run simultaneously

• Dirty reads: A dirty read occurs when a change made by one transaction can be seen by other transactions before the transaction has been committed Another transaction thus might think the row has been changed, even though that w ill not really be true i f the transaction that changed the row later is rolled back.

• Non-repeatable reads: A non-repeatable read refers to the failure by a transaction

to get the same result for a given SELECT statement each time it executes it This happens when a transaction reads the same row more than one time, and between the two (or more) reads, a separate transaction modifies that row Because the row was modified between reads within the same transaction, each read produces different values, which introduces inconsistency

• Phantom rows: A phantom row occurs when a transaction attempts to SELECT a row that does not exist and a second transaction inserts the row before the first

transaction fin ish es W hen the row is inserted, the row appears as a phantom to

the first transaction, inconsistently appearing and disappearing

To deal with these problems, MySQL supports four transaction isolation levels These levels determine which modifications made by one transaction can be seen byother transactions that execute at the same time:

READ UNCOMMITTED

A transaction can see row modifications made by other transactions even before they have been committed Transactions running at the READ UNCOMMITTED level

13

do not issue shared locks2 to prevent other transactions from modifying data read by the current transaction READ UNCOMMITTED transactions are also not blocked by exclusive locks3 that would prevent the current transaction from reading rows that have been modified but not committed by other transactions When this option is set, it is possible to read uncommitted modifications, which are called dirty reads Values in the data can be changed and rows can appear or disappear in the data set before the end o f the transaction This option has the same effect as setting NOLOCK on all tables in all SELECT statements in a transaction This is the least restrictive o f the isolation levels and it has no mechanism for concurrency control at all.

READ COMMITTED

A transaction can see row modifications made by other transactions only i f they have been committed This prevents dirty reads Data can be changed by other transactions between individual statements within the current transaction, resulting in non-repeatable reads or phantom data

REPEATABLE READ

I f a transaction performs a given SELECT twice, the result is repeatable That is,

it gets the same result each time, even i f other transactions have changed or inserted rows

in the meantime Informally, it specifies that statements cannot read data that has been modified but not yet committed by other transactions and that no other transactions can modify data that has been read by the current transaction until the current transaction completes

2 Shared lock (S lock o r read lock) is a technique that allows other transactions to read but not update a record o r other resource

Shared locks are placed on all data read by each statement in the transaction and are held until the transaction completes This prevents other transactions from modifying any rows that have been read by the current transaction Other transactions can insert new rows that match the search conditions o f statements issued by the current transaction I f the current transaction then retries the statement, it w ill retrieve the new rows, which results in phantom reads Because shared locks are held to the end o f a transaction instead

o f being released at the end o f each statement, access is more restricted than the default READ C O M M ITTED isolation level

3 E xclu sive lo c k (X lo ck o r w r ite lo c k ) is a technique that prevents another transaction from reading and therefore updating a record u n til it is unlocked.

1

Range locks4 are placed in the range o f key values that match the search

conditions o f each statement executed in a transaction This blocks other transactions from updating or inserting any rows that would qualify for any o f the statements executed

by the current transaction This means that i f any o f the statements in a transaction are executed a second time, they w ill read the same set o f rows The range locks are held until the transaction completes This is the most restrictive o f the isolation levels because

it locks entire ranges o f keys and holds the locks until the transaction completes

The follow ing table summarizes the differences between the four SQL isolation

levels

Isolation

Non- repeatable Reads

PhantomRowsRead

Table 1: Properties of SQL isolation levels

To have a clearer understanding about isolation levels, consider the following

examples:

In the following examples, we w ill work on the following table:

4 Key-range locks protect a range o f rows im p lic itly included in a record that being read w hile usirg the serializable transaction isolation level Key-range locking prevents phantom reads B y protecting

the -anges o f keys between rows, it also prevents phantom insertions o r deletions into a record set accessed

by г transaction.

C ustom er

T able 2: C ustom er table

Example 3 (D irty read): Assume that we have two transactions Tj and 丁2 asFigure 4

Ti T2

SELECT * FROM custoznsr WHERE id = 1;

UPDATE customer SET age » 20 WHERE id - 1;

/ * No c o n u n l t h e r e * /

SELECT * FROH

Figure 4: Dirty read

First transaction T ị r e a d s customer table to query information for customer id

=1 And the result may look like this:

It is obvious that transaction T ị has read the uncommitted data I f the transaction

丁2 rolls back the changes, so the result for second query o f transaction T] is inconsistent

17

Among the four levels o f isolation, READ U N C O M M ITTE D is the only levelthat allows this problem to happen.

Exam ple 4 (non-repeatable read): Suppose that we have two transactions like

Figure 5

SELECT * FRCÄ4 customer WHERE id = 1;

COM4IT；

Figure 5: Non-repeatable read

In this example, transaction T2 commits successfully, which means that its changes to the row w ith id = 1 should become visible to other transactions Transaction

Tị has already seen a different value for age in that row A t the S E R IA LIZ A B LE and REPEATABLE R EAD isolation level, the DBM S must return the old value (age = 25)

A t READ C O M M ITT E D and READ U N C O M M ITTE D , the DBMS may return the updated value (age = 20)，this is a non-repeatable read

Example 5 (phantom read): Consider two transactions, which are shown in Figure 6

Note that transaction Ti executed the same query twice I f the highest level o f isolation were maintained, the same set o f rows should be returned both times, and indeed that is what is mandated to occur in a database operating at the SQL SER IALIZABLE isolation level However, at the lesser isolation levels，a different set o f rows may be returned the second time

/ *Query 1 */

SELECT * FROM customer

WHERE age BETWEEN 15 AND 30 ；

/ * Q u e r y 2 * /

INSERT INTO customer VALUES (3 r 'An', 22);

COMMIT;

/ * Q u e r y 1 V

SELECT * FROM customer

WHERE age BETWEEN 15 AMD 30;

Figure 6: Phantom reads

In the SER IALIZABLE isolation mode, query 1 would result in all records with age in the range 15 to 30 being locked, thus query 2 would block until the first transaction was committed In REPEATABLE READ mode, the range would not be blocked，

allowing the record to be inserted and the second execution o f query 1 to return the new row in its results

The default InnoDb isolation level is REPEATABLE READ This can be changed at

s e r v e r startup w ith th e — t r a n s a c t i o n — isolation option or at ru n tim e w ith th e SET

TRANSACTION statement (Dubois 2009, p 182) An isolation level can be set by using the following syntax:

Chapter 3 Airline reservation system

To demonstrate concurrency control and its effects on a database system, I decided to choose airline reservation system as a demo system Since my initial goal is not building a full website for an airline reservation system but working on how to apply concurrency control theory in a real system, the demo system was created with a few simple functions The customers choose their desired flight from a list o f flights in the home pag, then the system asks the customers to enter the number o f seat(s) they want to reserve I f that flight has enough available seats for the customer’ s reservation, the customer provides their personal information such as name, address, phone number, credit card number and submits the order In case that flight does not have enough available seats, the system notifies the customer and then asks them to choose another flight For simplicity, this demo system w ill not provide any functions for customers to search for flights, choose type o f seat etc., or any mechanism for validating credit card number Furthermore, it is assumed that all information customers enter in the system forms are correct

Database design

The ER diagram o f this system is described as in Figure 7 One customer can have one or many reservations Each reservation is reserved for only some seats in one flight However, a flight can have zero or many reservations from customers

F ig u re 7: E R d ia g ra m

The airline reservation system basically includes three tables: flight, customer and reservation The structure o f table flight is as Figure 8 This table stores all information about flights such as flight number, date and time, destination place or how many available seats are left

g3 Server: localhost ^ gĩỉ Database: airline reservation ^ Oil Table: flight

Figure 8: Flight table

When a customer makes a reservation on the system, his personal information is kept in a table named customer Structure o f this table is shown in Figure 9

gg Server: localhost ^ Database: airline reservation ^ юз Table: customer

HBrowsa gf Structure 為 SQL Search _ ÌÉ Insert J g l Export _월 Import i f Operations J

Figure 9: Customer table

21

The airline reservation system stores detail transaction in reservation table, which

! It nũm ᄂbooktd { int(5) unsigned

Ш resv time : UmtsUmp

0PỈỊ airünej^sçry^(ic.r« li«M

• 합 id : ir<5) unsigned I© numb«r Î v«rch«r(10)

Figure 11: Table relationship

Data objects and classes

For easy management, the airline reservation system contains three objects: flight, customer, and reservation Each object has its own class

Class flight: This class includes functions for maintain executions in table flight

is shown in Figure 10 This table records how many seats a customer reserved for a flight The cus id and fligh니 d are foreign key which reference lo id field o f customer table and

flight table, respectively

Server: localhost ^ ¿ijb Database: airline reservation ^ 보|] Table: reservation

p Browse eS Structure 々 SQL Search F Insert 圈 Export 腫 Import 欠 Operations n b m p ty I

yp(

Tp

p

rs:

n t

n

St:

Function listAIIFlightO

о Input: None

о Return: an array that contains information o f all flights in the database

ᄋ Description: This function reads entire flight table

Function getFlightInfo($flightID)

о Input: id o f a flight

ᄋ Return: an array that contains detail information o f a flight

ᄋ Description: This function reads flight table where id o f flight is SflightlD.Function getFlightSeat($flightID)

о Input: id o f a flight

о Return: number o f seat that a flight has

ᄋ Description: This function read num seat in flight table where id o f flight

о Description: This function will call function total BookedSeat($flightID) in

reservation class for calculating number o f seats are booked in a flight and function getFlightSeat for getting number o f seat a flight has to update avai_seat in a flight whose id is SflightlD

Class reservation: This class contains functions used for booking a reservation.Function newReservation ($cusID,$flight id,$num seat book)

о Input: customer id, flight id, number o f seat a customer want to book

ᄋ Output: none

о Description: This function w ill insert into reservation table a new record

- Function totalBookedSeat (îflig h tID )

ᄋ Input: id o f a flight, number o f seat a customer wants to book

ᄋ Output: true or false

ᄋ Description: this function calls calAvaiSeat flinction and check whether

n u m b er o f se a ts a c u sto m e r w a n ts to b o o k is larger a v a ila b le s e a ts n u m b er

о Input: name, address, phone number, email, credit card number o f a customer

о Return: none

о Description: This function inserts a new record in customer table

- Function getCustomerlD ($name,$cardNum)

ᄋ Input: name, credit card number o f a customer

о Return: id o f a customer

ᄋ Description: this function read id in Customer table where customer’ sname and credit card number are $name and ScardNum respectively

- Function isCustomer ($name,$address,$phone,$cardNum)

о Input: name, address, phone number, credit card number

ᄋ Return: true or false

ᄋ Description: this function reads entire Cutomer table to find a customer whose name, address, phone and credit card number is exactly as input values

Class myFun: This class contains helper function used to process database

queries and check for error return codes, and to perform common html page navigation functions

Reservation Process

When a customer wants to reserve for a seat, he has to follow the following steps:

- Customer select a flight he wants to book from a list o f flights

- Customer enters nu m b er o f seats he wants to book

- Customer clicks on check availability button

2