Mc0914052 1

DESIGN AND IMPLEMENTATION OF TRANSACTION
PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE
UNDER CONCURRENT ACCESS.

BY

OLUWAKEMI YERA
0914052

A DISSERTATION SUBMITTED IN PARTIAL FULFILMENT OF THE
REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE (MSc) IN BUSINESS
INFORMATION SYSTEMS

DEPARTMENT OF COMPUTER SCIENCE & TECHNOLOGY

UNIVERSITY OF BEDFORDSHIRE, LUTON

UNITED KINGDOM

Supervisor: Dr. Marc Conrad

DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM
AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS

THESIS AUTHOR CONSENT FORM

AUTHOR’S NAME: OLUWAKEMI YERA

TITLE OF THESIS: DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM
AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS.

DEGREE: MSc BUSINESS INFORMATION SYSTEMS

Please read carefully and sign the following as appropriate.

I have read and understood the University’s regulations and procedures concerning the
submission of my thesis.
I understand that I have already signed a declaration agreeing to my dissertations being kept
in the Learning Resources Centre (LRC) when I enrolled.
We would like now, to extend this agreement by making the thesis available online. Further
to this,

I AGREE AS FOLLOWS:
- That I am the author of the work.
- That I have exercised reasonable care to ensure that the Work is original, and does not to
the best of my knowledge break any UK law or infringe any third party’s copyright or other
Intellectual Property Right.
- The LRC and BREO administrators do not hold any obligation to take legal action on behalf
of the Depositor (you), or other rights holders, in the event of breach of intellectual
property rights, or any other right, in the material deposited.

DELETE ONE OF THE FOLLOWING OPTIONS AS APPROPRIATE:
1. I hereby extend my consent to this thesis being included in the LRC as well as on BREO via
online access.

AUTHOR’S PERSONAL SIGNATURE: Oluwakemi Yera

AUTHOR’S STUDENT NUMBER: 0914052

DATE: 22 September, 2010.

0914052 OLUWAKEMI YERA
2


ABSTRACT

Utilisation of Online Transaction Processing Systems (OLTP) has never being so enormous since
its invention; most businesses have to acquire an online presence to reach a wider range of
consumers for business diversity. These systems are being developed and engineered according
to business requirements; this involves working in close proximity with developers to ensure
the systems meet functional requirements and Service Level Agreements (SLAs).

In recent times, there are various free resources which enable the development of databases
and websites within a matter of days. These resources often require technical knowhow which
are readily available online. Determined novices can develop an OLTP website for their small
businesses and even connect it to an active database without having to pay a fortune for it.

System testing for OLTPs involves many procedures, most businesses prefer to emphasise more
on User Acceptance Testing (UAT) while others will invest on testing and resolving issues of the
performance of their system before it goes live.

This dissertation is going to emphasize on the analysis of the developed system’s performance
when accessed with more than one user. Development of this system is also going to be
documented along with recounting on Transaction Processing Systems (TPSs).

3


ACKNOWLEDGEMENT

I would like to thank my supervisor, Dr Marc Conrad, for his advice and encouragement
throughout this project, my colleagues for being part of a wonderful learning experience in this
institute, my parents for their love and support and most of all to God Almighty for bestowing
unto me the upmost grace and knowledge.

4


DEDICATION

For Mum, I love you.

5


TABLE OF CONTENTS

THESIS AUTHOR CONSENT FORM .........................................................................................2

ABSTRACT ................................................................................................................................3

ACKNOWLEDGEMENT .............................................................................................................4

DEDICATION..............................................................................................................................5

TABLE OF CONTENTS .............................................................................................................6

LIST OF FIGURES .....................................................................................................................9

LIST OF TABLES .....................................................................................................................12

CHAPTER ONE: INTRODUCTION..........................................................................................13

1.1 PROBLEM DEFINATION ........................................................................................... 16
1.2 SCOPE AND FOCUS ................................................................................................. 16
1.3 AIM AND OBJECTIVES OF THE PROJECT .............................................................. 16
1.3.1 AIM.......................................................................................................................... 16
1.3.2 OBJECTIVES .......................................................................................................... 17
1.4 PROJECT METHODOLOGY ..................................................................................... 17
1.4.1 PRIMARY RESEARCH ........................................................................................... 18
1.4.2 SECONDARY RESEARCH ..................................................................................... 18
1.4.3 PROJECT CASE STUDY ........................................................................................ 18
1.5 OUTLINE OF CHAPTERS.......................................................................................... 18

CHAPTER TWO: LITERATURE REVIEW ...............................................................................20

2.1 TRANSACTION PROCESSING SYSTEMS (TPS): DEFINATIONS AND STRUCTURES
........................................................................................................................................... 20
2.1.1 INITIAL DEFINATIONS (TPS) .................................................................................... 21
2.1.2 SERIALISABILITY ..................................................................................................... 22
2.1.3 SERIAL LOGS ........................................................................................................... 23
2.1.4 TRANSACTION, RESOURCE AND DATABASE MANAGERS ................................. 25

6


2.1.5 CONCURRENCT CONTROL IN TPSS ....................................................................... 27
2.1.5.1 TWO PHASE COMMIT (2PC) .................................................................................. 32
2.1.6 PERFORMANCE OF TPSS ........................................................................................ 33
2.2 TPS STRUCTURES ...................................................................................................... 38
2.2.1 CENTRALISED TPS STRUCTURE............................................................................ 38
2.2.2 DISTRIBUTED DATABASE AND TPS STRUCTURE ................................................ 39
2.2.3 OLTP STRUCTURE ................................................................................................... 41
2.3 BREAKDOWN ON TPS DRAWBACKS ........................................................................ 42
2.3.1 RECOUNT ON TRANSACTION PROCESSING SYSTEMS ....................................... 42
2.4 SECURITY RISKS ASSOCIATED WITH TPSS ............................................................. 43
2.5 BUSINESS BENEFITS OF TPS .................................................................................... 44

CHAPTER THREE: DESIGN, DEVELOPMENT AND IMPLEMENTATION ..............................45

3.1 DESIGN AND STRUCTURAL INFORMATION ............................................................. 45
3.2 REQUIREMENTS SPECIFICATION ............................................................................. 46
3.3 ACTIVITY DIAGRAM .................................................................................................... 48
3.4 USE CASE .................................................................................................................... 49
3.5 SYSTEM IMPLEMENTATION ....................................................................................... 50
3.5.1 FRONT END .............................................................................................................. 52
3.5.1.1 ADMINISTRATOR'S INTERFACE ........................................................................... 53
3.5.1.2 USER'S INTERFACE .............................................................................................. 55
3.5.2 BACK END DATABASE ............................................................................................. 56

CHAPTER FOUR: TESTING ...................................................................................................59

4.1 TESTING TECHNIQUE ................................................................................................. 59
4.1.1 INTRODUCING WEB PERFORMER LOAD TESTER 4.1 ........................................... 60
4.2 TEST STRATEGY ......................................................................................................... 61
4.3 PERFORMANCE TEST ................................................................................................ 62
4.4 DEVELOPING PERFORMANCE TEST CASE .............................................................. 64
4.5 DEVELOPING PERFORMANCE TEST (LOAD) CONFIGURATIONS .......................... 66
4.6 RUNNING PERFORMANCE TEST ............................................................................... 68

CHAPTER FIVE: ANALYSIS AND DISCUSSION OF FINDINGS ...........................................70

7


5.1 RESPONSE TIME ....................................................................................................... 70
5.2 CONCURRENT ACCESSIBILITY ............................................................................... 71
5.3 TRANSACTION MIX ................................................................................................... 72
5.4 OTHER FINDINGS ...................................................................................................... 72
5.4.1 WAITING USERS AND AVERAGE WAIT TIME ......................................................... 72
5.4.2 PAGE DURATION ...................................................................................................... 73
5.4.3 FAILURES.................................................................................................................. 74

CHAPTER SIX: CONCLUSION AND RECOMMENDATION ...................................................74

6.1 CONCLUSION .............................................................................................................. 74
6.2 RECOMMENDATION FOR FUTURE RESEARCH ....................................................... 75

REFERENCES .........................................................................................................................76

APPENDICES...........................................................................................................................79

APPENDIX A: SCREEN SHOTS OF WEB PAGES............................................................. 79
APPENDIX B: SCREEN SHOTS OF DATABASE .............................................................. 81
APPENDIX C: PROJECT SUMMARY, NETWORK FLOW DIAGRAM, COMPLETED TASKS
AND GANTT CHART. ......................................................................................................... 85
APPENDIX D: PRODUCT BREAKDOWN STRUCTURE .................................................... 89
APPENDIX E: TEST RESULTS .......................................................................................... 90
APPENDIX F: OVERALL SYSTEM PERFORMANCE TEST RESULTS ............................. 91
PAGE DURATION .............................................................................................................. 91
PAGE COMPLETION RATE ............................................................................................... 91
TRANSACTION (URL) COMPLETION RATE...................................................................... 92
FAILURES .......................................................................................................................... 92
BANDWIDTH CONSUMPTION ........................................................................................... 93
CASES/MINUTE ................................................................................................................. 93
WAITING USERS ............................................................................................................... 94
APPENDIX G: USER MANUAL .......................................................................................... 96
APPENDIX H: THESIS POSTER ........................................................................................ 99

8


LIST OF FIGURES

FIGURE 1: STATE TRANSITION DIAGRAM SHOWING THE STATES FOR
TRANSACTION EXECUTION AS ILLUSTRATED BY ELMASRI AND NAVATHE
(2000) .......................................................................................................................... 14
FIGURE 2: SERVER RESPONSE TIME VERSUS UTILISATION ...................................... 15
FIGURE 3: PRINCE2 APPROACH TO PROJECT MANAGEMENT .................................. 17
FIGURE 4: THESIS STRUCTURE...................................................................................... 19
FIGURE 5: APPLICATION MANAGER- RESOURCE MANAGER- TRANSACTION
MANAGER RELATIONSHIP ....................................................................................... 26
FIGURE 6: LOST UPDATE SCENARIO. (SOURCE: HTTP://WWW.SQL-SYS.COM/SQL-
SERVER-RESOURCES/TRANSACTIONS/17-CONCURENCYISSUES.HTML) ......... 28
FIGURE 7: UNCOMMITTED DEPENDENCY (DIRTY READS) SCENARIO. (SOURCE:
HTTP://WWW.SQL-SYS.COM/SQL-SERVER-RESOURCES/TRANSACTIONS/17-
CONCURENCYISSUES.HTML) .................................................................................. 29
FIGURE 8: INCONSISTENT ANALYSIS SCENARIO. (SOURCE: HTTP://WWW.SQL-
SYS.COM/SQL-SERVER-RESOURCES/TRANSACTIONS/17-
CONCURENCYISSUES.HTML) .................................................................................. 30
FIGURE 9: PHANTOM READ SCENARIO. (SOURCE: HTTP://WWW.SQL-SYS.COM/SQL-
SERVER-RESOURCES/TRANSACTIONS/17-CONCURENCYISSUES.HTML) ......... 31
FIGURE 10: TWO PHASE COMMIT PROTOCOL (BERNSTEIN A. AND NEWCOMER E.,
2009) ........................................................................................................................... 32
FIGURE 11: KEYING TIME, RESPONSE TIME AND WAITING TIME IN A TRANSACTION
(SOURCE: HTTP://WWW.TPC.ORG/TPCC/SPEC/TPCC_CURRENT.PDF) .............. 34
FIGURE 12: ILLUSTRATES THE LOCATION OF RESPONSE TIME MEASUREMENT
(SOURCE: HTTP://WWW.TPC.ORG/TPCC/SPEC/TPCC_CURRENT.PDF) .............. 36
FIGURE 13: SINGLE USER TPS AS ILLUSTRATED BY BERNSTEIN ET AL (2009) ...... 38
FIGURE 14: MULTIUSER CENTRALISED TPS AS ILLUSTRATED BY BERNSTEIN ET AL
(2009) .......................................................................................................................... 39
FIGURE 15: STRUCTURE OF A DISTRIBUTED DATABASE SYSTEM AS ILLUSTRATED
BY SINGHAL AND SHIVARATRI (1994) .................................................................... 40
FIGURE 16: DISTRIBUTED TPC STRUCTURE ................................................................. 41
FIGURE 17: STRUCTURE OF A BASIC OLTP SYSTEM .................................................. 42
FIGURE 18: SECURITY POINTS BEFORE ACCESS TO DBMS....................................... 43

9


FIGURE 19: HOUSEHOLD ACCESS TO INTERNET (SOURCE: HTTP: //WWW.
LIKENCOM425J1.WORDPRESS.COM) ..................................................................... 44
FIGURE 20: INCREASE IN WEBSITES (SOURCE: HTTP: //WWW. FIRSTMONDAY.ORG)
.................................................................................................................................... 44
FIGURE 21: PROTOTYPING APPROACH TO SOFTWARE DEVELOPMENT (SOURCE:
HTTP://WWW.FREETUTES.COM/SYSTEMANALYSIS/SA2-PROTOTYPING-
MODEL.HTML) ............................................................................................................ 46
FIGURE 22: THREE TIER SYSTEM STRUCTURE ............................................................ 47
FIGURE 23: FREE WEB HOSTING SITE, ZYMIC.COM .................................................... 47
FIGURE 24: CASE STUDY TPS ACTIVITY DIAGRAM ...................................................... 48
FIGURE 25: USE CASE DIAGRAM FOR OUR CASE STUDY TPS .................................. 49
FIGURE 26: SPLIT SCREEN FEATURE OF ADOBE DREAMWEAVER CS5 ................... 50
FIGURE 27: WEBSITE PAGES AND SUMMARY OF THEIR FUNCTIONS ....................... 51
FIGURE 28: HULLFATE DIRECT HOME PAGE ................................................................ 52
FIGURE 29: EDITING WEB PAGES VIA ADOBE DREAMWEAVER ................................ 53
FIGURE 30: EDITING DATABASE USING MYSQL ON PHPMYADMIN ........................... 54
FIGURE 31: FACILITY FOR EDITING WEB PAGE CODES ON THE WEB HOSTING SITE
.................................................................................................................................... 54
FIGURE 32: FACILITY FOR UPDATING DATABASE ON THE WEB HOSTING SITE ..... 55
FIGURE 33: PRODUCTS PAGE ........................................................................................ 56
FIGURE 34: DATABASE CONNECTION CODE ................................................................ 57
FIGURE 35: PHP CODE CONNECTING THE ‘PRODUCTS’ PAGE QUERIES TO
INVENTORY DBMS .................................................................................................... 57
FIGURE 36: SQL QUERY USED TO CREATE THE PRODUCTS TABLE IN THE
DATABASE ................................................................................................................. 58
FIGURE 37: APPLICATION DATABASE DIAGRAM ......................................................... 58
FIGURE 38: BLACK BOX TESTING ILLUSTRATED ........................................................ 60
FIGURE 39: WHITE BOX TESTING ................................................................................... 60
FIGURE 40: LOAD TESTER ARCHITECTURE (SOURCE:
HTTP://WWW.WEBPERFORMANCEINC.COM/LIBRARY/WHITEPAPERS/CNAV/SYS
TEMDIAG.JPG) ........................................................................................................... 61
FIGURE 41: TEST CASE ................................................................................................... 66
FIGURE 42: WEB PERFORMER CONFIGURATION FOR TEST CASE ........................... 67
FIGURE 43: ILLUSTRATION OF RAMPING UP AND DOWN AND INTERVAL WHERE
DATA SHOULD BE COLLECTED (TPC, 2010). ......................................................... 68
FIGURE 44: TEST AT 1.15 MINUTES; ILLUSTRATES RAMPING UP .............................. 68

10


FIGURE 45: TEST AT 5.02 MINUTES WHEN ALL VIRTUAL USERS HAVE ACCESSED
THE WEBSITE ............................................................................................................ 69
FIGURE 46: TEST AT 22.40 MINUTES; RAMPING DOWN ............................................... 69
FIGURE 47: RAMPING UP, STEADY ACCESS AND RAMPING DOWN OF THE TEN
VIRTUAL USERS USED ............................................................................................. 71
FIGURE 48: WAITING USERS ........................................................................................... 73
FIGURE 49: PAGE DURATION ......................................................................................... 73
FIGURE 50: FAILURES ..................................................................................................... 74
FIGURE 51: HOME PAGE.................................................................................................. 79
FIGURE 52: PRODUCTS PAGE ........................................................................................ 79
FIGURE 53: CONFIRMATION PAGE ................................................................................. 80
FIGURE 54: HELP PAGE ................................................................................................... 80
FIGURE 55: COMPLETE DATABASE SHOWING THE THREE TABLES ON
PHPMYADMIN ............................................................................................................ 81
FIGURE 56: COLLABORATION TABLE ON PHPMYADMIN ............................................ 81
FIGURE 57: PRODUCTS TABLE ON PHPMYADMIN ....................................................... 82
FIGURE 58: STOCK TABLE ON PHPMYADMIN ............................................................... 82
FIGURE 59: DATABASE ON SQL BUDDY ....................................................................... 83
FIGURE 60: PRODUCTS TABLE ON SQL BUDDY........................................................... 83
FIGURE 61: STOCK TABLE ON SQL BUDDY .................................................................. 84
FIGURE 62: COLLABORATION TABLE ON SQL BUDDY ............................................... 84
FIGURE 63: PROJECT SUMMARY ................................................................................... 85
FIGURE 64: COMPLETED TASKS .................................................................................... 87
FIGURE 65: GANTT CHART A .......................................................................................... 87
FIGURE 66: GANTT CHART B .......................................................................................... 88

11


LIST OF TABLES

TABLE 1: ALLOCATION OF LOGS TO TRANSACTIONS (SINGHAL AND SHIVARATRI,
1994) ........................................................................................................................... 23
TABLE 2: INTERMINGLED LOG AND SERIAL LOG (SINGHAL AND SHIVARATRI, 1994)
.................................................................................................................................... 24
TABLE 3: (L1) INTERMINGLED LOG ................................................................................ 24
TABLE 4: (L2) SERIAL LOG.............................................................................................. 25
TABLE 5: SUMMARY OF THE TRANSACTIONAL MIX, KEYING TIME, AND RESPONSE
TIME CONSTRAINTS (TPC BENCHMARK REVISION 5.11, 2010) ............................ 33
TABLE 6: COMPARING DIFFERENT SYSTEMS AND THEIR CHARACTERISTICS
(BERNSTEIN AND NEWCOMER, 2009) ..................................................................... 37
TABLE 7: TEST STRATEGY ILLUSTRATED .................................................................... 62
TABLE 8: EXPECTED RESPONSE TIME FOR NEW ORDER AND STOCK LEVEL
TRANSACTIONS ........................................................................................................ 63
TABLE 9: LOAD CONFIGURATION .................................................................................. 63
TABLE 10: MINIMUM TRANSACTION MIX PERCENTAGE FOR NEW ORDER AND
STOCK LEVEL ............................................................................................................ 64
TABLE 11: TEST CASE INFORMATION ........................................................................... 65
TABLE 12: LOAD CONFIGURATION ................................................................................ 67

12


CHAPTER ONE: INTRODUCTION
The use of transaction processing systems has evolved in the past four decades with the ever
increasing usage in every aspect of information processing, from paper transactions to
electronic transactions with the use of the internet in purchasing goods, trading commodities
and acquiring information. Even the simple task of browsing the internet requires exchange of
information which is regarded as transactions. Thomasian A., (1998, p.173) asserts that “there
is an ever-increasing demand for more complex transactions and higher throughputs in
transaction processing systems leading to higher degrees of transaction concurrency and
hence, higher data controversies”. Thomasian in this regard, is trying to relate the use of
transaction processing systems in everyday routines; getting cash from the ATM machines,
shopping, buying parking tickets and lots more with the high number of transactions these
actions can generate and the number of transaction failures that can occur. Transactions
include the exchange of information which usually involves payments requiring adequate
measures to ensure data is stored and transmitted securely to preserve data integrity and
serialisability. Transactions are either completed (committed) or aborted, no intermediate form
is acceptable (Ho M., 2000). Hong C. (2005) also understood that a program tells the database
that it is about to begin executing a new transaction by issuing the operation-start, it indicates
the termination of the transaction by issuing either the operation-commit or the operation-
abort. He went further to suggest that when a program issues a ‘Commit’, the program is telling
the database management system (DBMS) that the transaction has terminated normally and all
of its effects should be made permanent, by issuing an ‘Abort’, the program tells the DBMS that
the transaction has terminated abnormally and all of its effects of that transaction should be
eliminated. Transaction processing systems usually need to be able to handle concurrent
access; this brings us to the issue of serialisability which is an important aspect of concurrency.
Serialisability ensures that database transitions from one state to the other are based on a
serial execution of all transactions (Bhargava B., 1999). Most businesses including the retail
sector utilize real-time transaction processing systems to support their business operations.

According to Powers G. (2000), one of the reasons and an important one at that in which these
real-time processing systems are widely employed are because of fast response time to user

13


queries, he also stated the following reasons for the high utilization of transaction processing
systems:
 Speedy performance,
 Rigidity in processing different transactions in equivalent manner,
 Reliability and
 Controlled processing; supporting an organisation’s operations.

READ/WRITE

BEGIN
TRANSACTION END
TRANSACTION COMMIT

PARTIALLY COMMITTED
ACTIVE
COMMITTED

ABORT
ABORT

FAILED TERMINATED

Figure 1: State transition diagram showing the states for transaction execution as illustrated by Elmasri and Navathe
(2000)

Figure 2 shows the level at which response time increases with rise in load (concurrent users);
for stable performance, it is necessary to keep the system operating below the point where the
response time dramatically increases (IBM Information Centre, 2010). Kehtarnavaz N. And
Gamadia M. (2006) believes that a real-time transaction processing system is one that must
satisfy explicit bounded response time constraints to avoid failure. In relation to this, response
time can be established to be important as most users will not appreciate web page loading
longer than necessary when either browsing or purchasing items online. A real-time system is

14


one that must satisfy explicit bounded response time constraints to avoid failure. Real-time
transaction processing systems consists of databases, a connecting application facility which
interact with the databases and presentation facilities including user interfaces.

Figure 2: Server response time versus utilisation

According to Bhargava (1999), when multiple users access database objects residing in a
distributed database system, the problem of concurrency control arises. Bernstein and
Goodman (1981) describe the activity of coordinating concurrent accesses to a database in a
multiuser database as concurrency control. Subsequently, the study of concurrency controls in
transaction processing systems has included procedures which have been analyzed,
implemented and their different drawbacks documented in various journals and educational
materials. In this project, a dynamic website (transaction processing system) will be designed
and implemented, the performance of this website will be analysed under concurrent use and
software testing involving components of the system which will support basic business
procedures will be carried out.

15


1.1 PROBLEM DEFINATION

Despite all the benefits a real-time transaction processing systems can deliver, there are
unpredictable situations in the area of response time when these systems reach or exceed their
load capacities for user access. This cannot be good for a business especially for a company
which has an online presence as its only means of getting its services to its clients. The
questions of
 What a transaction processing system entails,
 How it can be developed and implemented and
 What improvements it can provide a company in its day to day business operations can be
enquired in this regard.

We also have to investigate the issue of response time which should not exceed 10 seconds in
normal production systems (IBM Information centre, 2010).

1.2 SCOPE AND FOCUS

The scope of this project will not exceed the design, instigation, testing of our online
transaction processing system for its performance when being accessed and basic system
testing procedures. The main focus entails studying technologies used in developing online
transaction system, deciding the technology to be applied in developing our case study website
and analysing its performance before deployment.

1.3 AIM AND OBJECTIVES OF THE PROJECT
1.3.1 AIM
The aim of this thesis is to develop and instigate an online transaction processing system for a
case study company and analyse the performance under concurrent access while also testing
the components of the developed system which are important to our case study retail
company’s business operations.

16


1.3.2 OBJECTIVES
The fundamental objectives of this project are:

 Developing and deploying an online transaction processing system for a case study retail
company via prototyping approach to software development,
 Model implementation using Hypertext Pre-processor (PHP), MySQL and Adobe
Dreamweaver CS5.
 Testing the model using black box and white box methodology of software testing,
 Automate performance test for system analysis and
 Development process management utilising PRINCE2 project management methodology.

1.4 PROJECT METHODOLOGY
This project’s methodology will be based on complete research including design and
development using PHP and HTML scripting languages, MySQL database query language and
Adobe Dreamweaver dynamic web building tool; all these will be used collectively to design
and develop our retail company’s database and website. The software development system to
be utilized will be prototyping as mentioned earlier and project management methodology,
PRINCE2.

DIRECTING A PROJECT

Starting a Initiating a Controlling a Managing Managing Closing a
project project project stage product project
boundaries delivery

PLANNING

Figure 3: PRINCE2 approach to project management

17


1.4.1 PRIMARY RESEARCH

Relevant publications will be utilized to support the general literature review of the different
sections of this project. Journals, white papers and trade magazines will also be consulted in the
process of writing this thesis.

1.4.2 SECONDARY RESEARCH

Research was carried out on transaction processing systems, methods of design and
implementation, system testing of basic business components, benchmarks from the
Transaction Processing Performance Council (TPC) and automation testing including the use of
Web Performance Load Tester.

1.4.3 PROJECT CASE STUDY
Our case study company, Hullfate Direct, has been around for a decade and their main business
area is retail. The company sells safety products to companies, trades and private customers.
They have made the decision to establish an online presence for their business believing it will
provide diversity to their business operations by increasing sales and improving customer
services. The transaction processing system to be developed will support the organisation’s
main business operation which is making products accessible to their clients.

1.5 OUTLINE OF CHAPTERS
The outline of chapters in this thesis is shown in figure 4 with concise reports of what they
include:
Chapter 1 illustrates the structure of the thesis and defines some key phrases in the project
title; it also shows the activities to be carried out in this project.
Chapter 2 re-evaluates broadly on previous study in the subject area. This chapter encompasses
the literature review.

18


CHAPTER 1
INTRODUCTION

CHAPTER 2 LITERATURE
REVIEW

CHAPTER 3
DESIGN, DEVELOPMENT
AND IMPLEMENTATION

CHAPTER 4
TESTING

CHAPTER 5
ANALYSIS AND
DISCUSSION OF FINDINGS

CHAPTER 6
CONCLUSION AND
RECOMMENDATION

Figure 4: Thesis structure

Chapter 3 gives details on the methodology employed, research model and procedure,
transaction processing system and webpage implementation. It also encompasses system
design and development. Problems encountered will be reviewed in this chapter.

19


Chapter 4 includes the testing of the developed system’s basic facilities and automation testing
of its performance.
Chapter 5 analyses and discusses results and findings from system testing.
Chapter 6 contains the conclusion and recommendations.

CHAPTER TWO: LITERATURE REVIEW

2.1 TRANSACTION PROCESSING SYSTEMS (TPS): DEFINATIONS AND
STRUCTURES
Bernstein et al (2009) defines a TPS as one or more databases that store the state of an
enterprise, the software for managing the transaction that manipulate that state and the
transactions themselves that constitute the application code. They can be single or multi user
systems but ideally they are multi user systems when it comes to e-commerce systems like our
case study retail company’s system. Transaction processing systems are a type of information
systems which provides tools to automate application programming, execution and
administration; they are usually geographically distributed, heterogeneous and support a
network of devices that present queries and updates to the application (Grey J. and Reuter A.,
1993). Sivasankaran M. et al (1995), define a real-time active database as a database system
where transactions have timing constraints such as deadlines, where transactions may trigger
other transactions and where data may become invalid with the passage of time. Usability is a
key factor for the success of online TPS and these systems must be designed to meet specific
usability objectives and accommodate a wide diversity of users (Kok D. and Wesson J., 2002).
Our website will undergo user testing of the frontend (for users) and backend (for
administrators); this will support usability testing as proposed by Kok and Wesson. According to
Thomasian A. (1998), transaction is processed in three phases:
 a read phase,
 a validation phase, followed immediately by
 a write phase, if the validation is successful.

20


Batch, real time transaction processing and data warehousing are three main types of
transaction processing systems:
 Batch transaction processing collects the transaction data as a group (batch) and processes
it at a later time e.g. cheque clearance or generating pay cheques.
 Real-time transaction processing is the immediate processing of data e.g. airline reservation
systems, banking transaction systems and e-commerce websites.
 Data warehouse systems where reporting and ad hoc queries access data that is integrated
from multiple data sources (Bernstein A. and Newcomer E., 2009).

Manual transaction processing systems are still used alongside computerized transaction
processing systems; evidently transaction processing was done manually on the onset of
business procedures such as stock taking however computerized transaction processing makes
it faster and easier to manage. The issue of computerising a business’s transaction processing
system relies on whether it can be afforded and if it will improve business objectives.
Ultimately, a transaction processing system must possess ACID properties; this is discussed in
the next section.

2.1.1 INITIAL DEFINATIONS (TPS)
An information system is a collection of interconnected components that collect, process, store
and distribute information to support decision making, coordination and control in an
organisation (Laudon J.P. And Laudon J.C., 2002). As a type of information systems, transaction
processing systems also inherit all the functions of an information systems so also does decision
support systems (DSS) and all other type of information systems. Bhargava B., (1999) defines
transactions as quantum changes of database form one constant state to another. Ho, M.
(2000) says transaction properties include Atomicity, Consistency (Serialisability), Isolation and
Durability (ACID):
 Atomicity: all parts of a transaction must be completed (committed) or aborted.
 Consistency (Serialisability): result of concurrent execution of several transactions is treated
as being executed in serial order.

21


 Isolation: data used during a transaction cannot be used by another transaction until the
first transaction is complete.
 Durability: consistent state of database when a transaction is completed must not be lost
even in the presence of system failure.

A distributed transaction processing system maintains the ACID properties in transactions by
using two features (IBM TXSeries for Multiplatforms):

 Recoverable processes. Recoverable processes log transaction actions and therefore can
restore earlier states if failure occurs.
 A commit protocol. A commit protocol allows multiple processes to coordinate the
committing or aborting of a transaction. The most common commit protocol is the two-
phase commit protocol which is discussed in details in section 2.1.5.1.

It was also denoted from IBM TXSeries for Multiplatforms that
“Recoverable processes can store two types of information: transaction state information
and descriptions of changes to data. This information allows a process to participate in a
two-phase commit and ensures isolation and durability. Transaction state information must
be stored by all recoverable processes. However, only processes that manage application
data (such as resource managers) must store descriptions of changes to data. Not all
processes that are involved in a distributed transaction need to be recoverable.”

2.1.2 SERIALISABILITY
Papadimitriou C. (1979) defines a sequence of transactions as serialisable when these
transactions are executed indivisibly, measured as the utmost point of separation amongst
transactions and performs an important function in concurrency control. Schedules (transaction
schedules) are serialisable if the operations of all transactions can be reordered in such a way
that afterwards the transactions can be executed completely one after another. He also
explained that if a schedule is serialisable, it is accurate (i.e. maintains the ACID principles) and
all transactions of the schedule can commit. If a schedule (also labelled scheduler) is not

22


serialisable, the schedule might be incorrect and at least one transaction has to be aborted. A
theory informative of serialisability as explained by Date C. J. (1995), explains that transaction
logs are records of all operations performed by a transaction and that each entry in a log
provides the following information:

 Operation type (read or write),
 Data on which the operation was performed and
 Transactions which performed the operation.

Misconception about the importance of serialisability occurs because it is believed that a
database system will have integrity constraints thus maintaining consistency, this can be a
tricky one as there are many consistency constraints that database systems can’t enforce
(Bernstein A. and Newcomer E, 2009).

2.1.3 SERIAL LOGS
Serial logs are representations of executions of transactions where actions from various
transactions do not intermingle (Singhal and Shivaratri, 1994). They also illustrated how serial
logs are generated for a unique transaction in table 1 and 2:

Transactions T1 T2 T3 T4
Serial logs
T1log = L1 T2log = L2 T3log = L3 T4log = L4

Table 1: Allocation of logs to transactions (Singhal and Shivaratri, 1994)

23


T1 = r1[x] r1[z] w1[x]

T2 = r2[y] r2[z] w2[y]

T3 = w3[x] r3[y] w3[z]

L1 = w3[x] r1[x] r3[y] r2[y] w3[z] r2[z] r1[z] w2[y] w1[x]

L2 = w3[x] r3[y] w3[z] r2[y] r2[z] w2[y] r1[x] r1[z] w1[x]

Table 2: Intermingled log and serial log (Singhal and Shivaratri, 1994)

In table 3, L1 shows an uncoordinated mixture of the transaction components; w3[x] from T 3
followed by r1[x] form T1 and then r3[y] form T3. L1 is an example of an intermingled log and so
can not represent a serial log.

T1 = 2 7 9
r1[x] r1[z] w1[x]
T2 = 4 6 8
r2[y] r2[z] w2[y]
T3 = 1 3 5
w3[x] r3[y] w3[z]

L1 = 1 2 3 4 5 6 7 8 9
w3[x] r1[x] r3[y] r2[y] w3[z] r2[z] r1[z] w2[y] w1[x]

L2 = w3[x] r3[y] w3[z] r2[y] r2[z] w2[y] r1[x] r1[z] w1[x]

Table 3: (L1) intermingled log

24


Whereas L2 shows a coordinated sequence of transaction components which are not
intermingled; w3[x], r3[y] and w3[x] from T3 followed by r2[y], r2 [z] and w2[y] from T2 and then
r1[x], r1[z] and w1[x] from T1.

T1 = 7 8 9
r1[x] r1[z] w1[x]
T2 = 4 5 6
r2[y] r2[z] w2[y]
T3 = 1 2 3
w3[x] r3[y] w3[z]

L1 = w3[x] r1[x] r3[y] r2[y] w3[z] r2[z] r1[z] w2[y] w1[x]

L2 = 1 2 3 4 5 6 7 8 9
w3[x] r3[y] w3[z] r2[y] r2[z] w2[y] r1[x] r1[z] w1[x]

Table 4: (L2) serial log

2.1.4 TRANSACTION, RESOURCE AND DATABASE MANAGERS
According to Bernstein A. and Newcomer E. (2009), transaction manager is a bookkeeper that
keeps track of transactions in order to ensure atomicity when more than one resource is
involved. They ascertained that a transaction manager processes the basic transaction
operations for applications which are: Start, Commit and Abort (Figure 1 explains these
procedures) and that they are located at each node of a distributed computer system (Figure 15
shows the location of transaction managers).

25


Application program

Transaction manager
Resource manager

Figure 5: Application manager- Resource Manager- Transaction Manager Relationship

The concept of resources in database systems, according to Bernstein and Newcomer (2009)
includes databases, queues, files, messages and all other objects that can be accessed within a
transaction. They also suggest that resource managers offer operations that must execute only
if the transaction that calls the operations commit. As detailed earlier, resource managers act
on messages from transaction managers during transactions to confirm execution of a
transaction. Whenever a transaction accesses a resource manager, the transaction manager
has to be notified so as to know which resource manger is responsible for which transaction
(Bernstein A. and Newcomer E., 2009). From all indications, transaction and resource managers
play important roles in the Two Phase Commit protocol as well as executing transactions.
Sivasankaran M. et al (1995, p.23) says

“Database manager is the passive module that models the data. The data is modelled as
having a certain number of object classes and each object class has a certain number of
instances. Each object class also has certain number of methods defined which are used
to access the object. Each object instance in the database is mapped to a page or number
of pages in secondary storage.”

26


2.1.5 CONCURRENCT CONTROL IN TPSs
The requirement for concurrency control in transaction processing systems cropped up twenty
years ago; it was developed to make sure of accuracy in a shared database when updated by
numerous transactions (Gray and Reuter, 1992). Bhargava B., (1999) explains that the purpose
of concurrency control is to assure that the simultaneous execution of a set of transactions
does not result in an unstable database state. The concurrency control scheme employed can
profoundly affect the performance of transaction processing systems (Yu et al, 1993). There are
setbacks in areas of concurrency control mechanisms like the two phased locks (2PL) often
implemented in these systems. There are other mechanisms which prove to provide more in
the area of concurrency control when solely used or combined depending on the business
sector its being utilized. Thomasian A., (1998) believes that conventional two-phase locking
(2PL) concurrency control method may restrict system throughput to levels inconsistent with
the available processing capacity. Without concurrency control, there are problems of lost
updates, uncommitted dependency (dirty reads), inconsistent analysis and phantom reads;
these occurrences are illustrated in figure 6, 7, 8 and 9.

27


DATA DATA
DATA
1 1
1
2 2
2
3 5
3
4 4
4
5 5
5

JOHN HARRY JOHN (VALUE=3) HARRY JOHN (VALUE=5) HARRY
() (VALUE=3)

STEP 1: STEP 2: STEP 3:

JOHN STARTS THE TRANSACTION. MEANWHILE HARRY STARTS JOHN CHANGES VALUE TO 5 AND
HE READS THE VALUE OF 3. ANOTHER TRANSACTION COMMITS THE TRANSACTION TO THE
oo HE READS THE VALUE OF 3 TOO. DATABASE

DATA DATA
1 1
2 2
7 7
4 4
5 5

JOHN (VALUE=5) HARRY (VALUE=7)

STEP 4: HARRY CHANGES VALUE TO 7 AND
JOHN (VALUE=5) HARRY(VALUE=7)
COMMITS THE TRANSACTION TO THE DATABASE

STEP 5: JOHN’S UPDATE IS LOST

Figure 6: Lost update scenario. (Source: http://www.sql-sys.com/sql-server-resources/transactions/17-
concurencyissues.html)

The Lost Updates issue occurs when two or more transaction read the same value and makes
updates to the value making the change made by the last transaction to be stored in database
and all others changes by other transactions lost (Przemyslaw C. 2010).

28


DATA DATA
DATA
1 1
1
2 2
2
5 5
3
4 4
4
5 5
5

JOHN HARRY JOHN (VALUE=5) HARRY JOHN (VALUE=5) HARRY
() (VALUE=5)


JOHN STARTS THE TRANSACTION. JOHN CHANGES VALUE TO 5 MEANWHILE HARRY STARTS
HE READS THE VALUE OF 3. ANOTHER TRANSACTION, HE READS
OO VALUE 5

DATA DATA
1 1
2 2
3 3
4 4
5 5

JOHN (VALUE=3) HARRY (VALUE=5)

STEP 4: JOHN REALISES THAT HE MADE A MISTAKE AND ROLLS
JOHN (VALUE=3) HARRY(VALUE=5)
BACK THE TRANSACTION CAUING VALUE TO BE RECOVERED BACK TO 3

STEP 5: ALTHOUGH THE VALUE WAS RECOVERED TO 3, HARRY 00
LKJHHG FTRTY READS THE VALUE OF 5.

Figure 7: Uncommitted dependency (dirty reads) scenario. (Source: http://www.sql-sys.com/sql-server-
resources/transactions/17-concurencyissues.html)

The Dirty Read occurs when the second transaction reads the value that is being updated by
another transaction; this usually happens when the user put the wrong value while in
transaction and rolls back the whole transaction (Przemyslaw C. 2010). The problem is also
called Uncommitted Dependency.

29


DATA DATA
DATA
1 1
1
2 2
2
5 5
3
4 4
4
5 5
5

JOHN HARRY JOHN (VALUE=5) HARRY JOHN (VALUE=5) ()
00 (VALUE =3) HARRY(VALUE=5)


HARRY STARTS THE TRANSACTION. JOHN CHANGES VALUE TO 5 HARRY READS THE VALUE AGAIN AND
HE READS THE VALUE OF 3. HE GETS THE OTHER VALUE THAT HE
OO ORIGINALLY READ.

DATA DATA
1 1
2 2
3 5
4 4
5 5

JOHN HARRY

STEP 4: HARRY STARTS THE TRANSACTION, HE READS THE VALUE OF 3. JOHN (VALUE=5) HARRY (VALUE=3)

STEP 5: JOHN CHANGES VALUE TO 5G FTRTY

Figure 8: Inconsistent analysis scenario. (Source: http://www.sql-sys.com/sql-server-resources/transactions/17-

The Non-repeatable Reads issue also called Inconsistent Analysis issue occurs when the second
transaction makes several reads of the same value and gets different values (Przemyslaw C.
2010). It is caused by the other transaction updates to the value. It is similar to Dirty Read
problem but in this case the second transaction makes several reads (Przemyslaw C. 2010).

30


DATA DATA
DATA
1 1
1
2 2
2
3 X
3
4 4
4
5 5

JOHN HARRY JOHN (NEW RECORD) HARRY HARRY ()
00 VALUE =1 JOHN (DELETE RECORD) VALUE=1
00 VALUE=2 VALUE=2

VALUE=3 VALUE=3
00 VALUE=4 VALUE=4

STEP 1: STEP 2: JOHN ADDS NEW RECORD WITH VALUE STEP 3: JOHN REMOVES RECORD WITH
HARRY STARTS THE TRANSACTION O OF 5. VALUE OF 3.

HE READS ALL RECORDS FROM THE TABLE.

STEP 4: HARRY READS THE WHOLE TABLE AGAIN DATA
AND GETS DIFFERENT RESULT SET, VALUEOF 3 1
DISAPPEARED, VALUE OF 5 APPEARED, THESE ARE 2
PHANTOM RECORDS. 4
5

VALUE=1
OO
VALUE=2

VALUE=4
JOHN
HARRY VALUE=5

Figure 9: Phantom read scenario. (Source: http://www.sql-sys.com/sql-server-resources/transactions/17-

According to Przemyslaw C. (2010),

“The Phantom Reads problem occurs when adding or deleting rows while other transaction
processes the same range of rows. When one transaction reads the range of rows and the
other one removes or inserts new rows in that range, phantom record may appear. These
rows won't be visible to the first transaction and after refreshing the result set, the
transaction will get different result set with new rows and without deleted rows. So, when
the transaction wants to process data it may happen that it won't do that right because
before commit new records may need to be processed, as well as few records may not
exist. “

31


Bernstein P. and Goodman N. (1981) think the main technical difficulty in attaining concurrency
controls in databases is preventing interference with database retrievals and updates. They
went further to explain that concurrency control problems can be aggravated in distributed
databases by retrieving stored data in multiple computers in distributed systems by users. Hong
C. (2005), believes concurrency control mechanism at one computer cannot instantaneously
know about interactions at another computer

2.1.5.1 TWO PHASE COMMIT (2PC)
Ensuring atomicity when a transaction updates on two or more database systems occurs by
both databases updating or aborting, this can be challenging because databases can either fail
or recover which is a problem when database systems reside on different nodes of a distributed
system, it can also be a problem in a single machine if the database systems run server
processes which can also fail independently (Bernstein A. and Newcomer E., 2009). Two phase
commit protocol is the proposed solution to this situation (Bernstein A. and Newcomer E.,
2009).

TRANSANCTION TRANSANCTION
MANAGER MANAGER

Prepare Prepare Commit Commit

I am prepared I am prepared OK OK

RESOURCE MANAGER RESOURCE MANAGER RESOURCE MANAGER RESOURCE MANAGER
IN LOCATION ONE IN LOCATION TWO IN LOCATION ONE IN LOCATION TWO

Phase One Phase Two

Figure 10: Two Phase Commit Protocol (Bernstein A. and Newcomer E., 2009)

32


With the help of the transaction manager, 2PC protocol is executed by storing durable portions
of transaction updates before transaction commits anywhere (Bernstein A. and Newcomer E.,
2009). Transaction manager sends two rounds of messages (one for each phase of the
commitment activity); the first round of message tells the resource managers to prepare to
commit by writing a copy of the results of the transaction to stable storage and the second
round of message actually tells resource managers to commit when it has ascertained that the
resource managers are ready to commit (Bernstein A. and Newcomer E., 2009).

2.1.6 PERFORMANCE OF TPSs
As mentioned earlier, response time is the basic measurement for performance in a TPS but
other aspects such as scalability, business throughput and storage capacities of connected
databases comes into play. System performances are unpredictable without testing even if
components performances are known thus vendors and users have implemented benchmarks
to obtain guidance on how to measure system performance (Bernstein A. and Newcomer E.,
2009). The Transaction Processing Performance Council (TPC) defines these benchmarks which
are going to be used in comparison to our performance test results. The following tables details
the benchmark from TPC Benchmark revision 5.11 (2010) for transaction processing systems
and their connected databases.

Transaction type Minimum % of Minimum keying 90th percentile Minimum mean
mix time response time of think time
constraint distribution
New order n/a 18 sec. 5 sec. 12 sec.
Payment 43.0 3 sec. 5 sec. 12 sec.
Order status 4.0 2 sec. 5 sec. 10 sec.
Delivery 4.0 2 sec. 5 sec. 5 sec.
Stock level 4.0 2 sec. 20 sec. 5 sec.

Table 5: Summary of the transactional mix, keying time, and response time constraints (Source:
http://www.tpc.org/tpcc/spec/tpcc_current.pdf)

33


Previous screen

Menu
1.Select transaction type

3.Measure menu RT
2.Display screen

Input screen
4. Wait (Keying time)
Menu

6. Measure Txn. RT
5.Display data

Output screen
Menu 7. Wait (Think time)

Figure 11: Keying time, response time and waiting time in a transaction (Source:
http://www.tpc.org/tpcc/spec/tpcc_current.pdf)

The New-Order business transaction consists of entering a complete order through a single
database transaction (TPC Benchmark revision 5.11, 2010). Hullfate’s TPS has the business
transaction facility to complete an order through a single database transaction by choosing a
product, choosing the quantity of the product required and clicking the ‘Purchase’ button; this
action reduces the stock quantity for that item in the database by the quantity purchased.
The Payment business transaction updates the customer's balance and reflects the payment on
the district and warehouse sales statistics (TPC Benchmark revision 5.11, 2010). Payment
business transaction facility is not available on Hullfate’s TPS.
The Order-Status business transaction queries the status of a customer's last order (TPC
Benchmark revision 5.11, 2010). This business transaction facility is also not available on
Hullfate’s TPS.

34


The Delivery business transaction consists of processing a batch of 10 new (not yet delivered)
orders (TPC Benchmark revision 5.11, 2010). Delivery business transaction facility is not
available on Hullfate’s TPS.
The Stock-Level business transaction determines the number of recently sold items that have a
stock level below a specified threshold (TPC Benchmark revision 5.11, 2010). Hullfate’s TPS
possesses this business transaction facility by displaying the ‘Product is out of stock’ message to
the user when the product or the quantity of products required is not available to order; these
are the specified thresholds.

Also according to the TPC, The 90th percentile response time for the New-Order, Payment,
Order-Status, Stock-Level and the interactive portion of the Delivery transactions must be
greater than or equal to the average response time of that transaction. If the 90th and the
average response times are different by less that 100ms (1 second), then they are considered
equal. This requirement is for the terminal response times only and does not apply to the
deferred portion of the Delivery transaction or to the menu step.

The TPC transaction mix represents a complete business cycle. It consists of multiple business
transactions which enter new orders, query the status of existing orders, deliver outstanding
orders, enter payments from customers, and monitor warehouse stock levels. Response time,
according to the TPC, is defined as:
 Each completed transaction submitted to the System under Test (SUT) must be individually
timed.
 Response times must be measured at the Remote Terminal Emulator (RTE).
 A Response Time (or RT) can also be explained as:
RT = T2 - T1

Where:
T1 and T2 are measured at the RTE and defined as:
T1 = timestamp taken before the last character of input data is entered by the emulated user.
T2 = timestamp taken after the last character of output is received by the emulated terminal.

35


Also according to the TPC, the intent of the minimum percentage of mix for each transaction
type is to execute approximately one Payment transaction for each New-Order transaction and
approximately one Order-Status transaction, one Delivery transaction, and one Stock-Level
transaction for every 10 New-Order transactions. This mix results in the complete business
processing of each order. New-order and stock-level are the transactions for Hullfate’s
complete business process and are going to represent its total transaction mix.

REMOTE TERMINAL EMULATOR

K/D TERMINAL NETWORK SYSTEM UNDER TEST
T

Network

S
T E
T SERVER SYSTEM(S)
R
Network V S -S
E
R Network

T
T

Network

K/D
T

Network

RESPONSE TIME

MEASURED HERE

T: TERMINAL

K/D: KEYBOARD DISPLAY

S-S: SERVER TO SERVER

Figure 12: Illustrates the location of response time measurement (Source: http://www.tpc.org/tpcc/spec/tpcc_current.pdf)

SUT as explained by TPC consists of:
 One or more processing units (e.g., host, front-ends, workstations, etc.) which will run the
transaction mix and whose aggregate performance.
 Any front-end systems are considered to be part of the SUT e.g. user interface
 The host system(s), including hardware and software, supporting the database employed

36


 The hardware and software components of all networks required to connect and support
the SUT components.
 Data storage media sufficient to satisfy both ACID properties of the transaction processing
system.

Transaction Batch Real-time Data Warehouse
processing
Isolation Serialisable, Serial, uni- No transaction No transaction
Multi- programmed concept concept
programmed execution
execution
Workload High variance predictable Predictability Predictable loading,
depends on the high variance queries
application
Performance Response time Throughput Response time, Throughput for
matrix and throughput throughput, loading, response time
missed deadlines for queries
Input Network of Record-oriented Network of Network of display
display devices file devices submitting devices submitting
submitting data and queries
requests operations
Data Access Random access Accesses sorted unconstrained Possibly sorted for
to be consistent loading, unconstrained
with database for queries
order
Recovery After failure, After failure, Application’s Application’s
ensure database rerun the batch responsibility responsibility
has committed to produce a new
updates and no file
others

Table 6: Comparing different systems and their characteristics (Bernstein and Newcomer, 2009)

In table 6, the difference between TPSs and other systems are illustrated showing where and
how TPSs are specially designed for business purposes and the sections that apply to TPS to be
developed in this project.

37


2.2 TPS STRUCTURES
Bernstein et al (2009) explains that the earliest TPSs are centralised due to hardware limitations
and he gave examples using a single personal computer or workstation servicing a single user,
or a mainframe computer with many connecting terminals servicing multiple users
concurrently.

2.2.1 CENTRALISED TPS STRUCTURE
Figure 13 shows the organisation of a single user TPS as illustrated by Bernstein et al (2009),
presentation facility displays forms on the screen and handle flow of information to and from
the user through the forms, it also communicates with the application facility to process user
requests. Application facility checks integrity constraints and executes the user requests while
communicating with the database server. In this situation, ACID properties are not required as
this system structure does not represent a business venture.

Centralised System

PRESENTATION APPLICATION DATABASE
FACILITY FACILITY DBMS

User Module

Figure 13: Single user TPS as illustrated by Bernstein et al (2009)

For a multi user system as illustrated in figure 14, ACID properties required are isolation as
DBMS observes an interrupted schedule, atomicity and durability (Bernstein et al, 2009).
This type of system structure supports a major business venture.

38


User Module

DBMS
PRESENTATION APPLICATION
FACILITY FACILITY
TRANSACTION DATA
DATABASE
SUPPORT ACCESS
FACILITY FACILITY

Centralised system

Figure 14: Multiuser centralised TPS as illustrated by Bernstein et al (2009)

2.2.2 DISTRIBUTED DATABASE AND TPS STRUCTURE

Figure 15 illustrates the communication between components of the distributed TPS; each
transaction presents its procedures to a single transaction Manager (TM), which receives the
procedures presented and accelerates them to the scheduler. Aybay I. And Halici U. (1995)
explains that

“In DBMSs, the TM is also responsible for determining which scheduler should process the
operation submitted by a transaction. As discussed before, the scheduler is accountable
for the database’s consistency. Though a scheduler does not pay attention to the
calculations performed by the transactions, it makes its assessment exclusively by
contemplating the type of the procedures and the data items connected to the
procedures. The scheduler manages the sequence in which Data managers (DM) manages
the read and write procedures. When a scheduler receives a read or a write procedure, it
can either produce the operation to the related DM, or suspend the operation by holding
it for later action, or reject the operation. If an operation of a transaction is rejected, then

39


the transaction should be aborted. Furthermore, every transaction that read a value
written by the aborted transaction should also be aborted. Usually, a scheduler decides
whether to accept, reject or delay a procedure every time it receives the procedure.
Another approach is to schedule each procedure immediately as it is received. When a
transaction terminates, a validation test is applied on the transaction. If the validation
test terminates successfully then the transaction is committed, otherwise it is aborted.
Such schedulers are called the optimistic schedulers because they optimistically assume
that transactions will not be aborted. The DM executes each read and writes operation it
receives. For a read operation, DM looks into its local database and returns the requested
value. For a write operation, the DM modifies its local database and returns an
acknowledgment. The DM sends the returned value or acknowledgment to the scheduler,
which relays it back to the TM, which relays it back to the transaction.”

TRANSACTION DATA
TRANSACTIONS SCHEDULER DATABASE
MANAGER MANAGER

TRANSACTIONS TRANSACTION DATA
SCHEDULER DATABASE
MANAGER MANAGER

TRANSACTIONS TRANSACTION DATA
SCHEDULER DATABASE
MANAGER MANAGER

Figure 15: Structure of a distributed database system as illustrated by Singhal and Shivaratri (1994)

40


Figure 16 shows the architecture of distributed TPS with separate and probably distantly
located sites. These systems are usually Online Transaction Processing Systems (OLTP).

SITE 1 SITE 2

NETWORK

SITE 3

Figure 16: Distributed TPC structure

2.2.3 OLTP STRUCTURE
The growth of the internet has stimulated the development of many internet services involving
transaction processing often with throughput requirements of thousands of transactions per
second and can be Customer-to-Business (C2B) services which usually involves people
interacting with the system through their browsers or Business-to-Business (B2B) services
which are usually fully automated allowing for programs on one business’s website to
communicate with programs on another business’s website (Radu G. 2005).

41


Centralised system

FACILITY FACILITY
DBMS

User section

Database server Application server Web server

Figure 17: Structure of a basic OLTP system

2.3 BREAKDOWN ON TPS DRAWBACKS

Bernstein and Goodman (1981) think the main technical difficulty in attaining concurrency
controls in databases of transaction processing systems is preventing interference with
database retrievals and updates. They went further to explain that concurrency control
problems can be aggravated in distributed DBMSs by retrieving stored data in multiple
computers in distributed systems by users.

2.3.1 RECOUNT ON TRANSACTION PROCESSING SYSTEMS
The first online transaction processing system to be recognised and used globally was SABRE,
an airline reservation system developed in the early 1960s by IBM and American Airlines
(Bernstein A. and Newcomer E., 2009). It is still one of the biggest TPS in the world and its peak
performance exceeds 20,000 messages per second (Bernstein A. and Newcomer E., 2009). Prior
to SABRE, computers were machines that first and foremost processed information and only
secondarily provided the functions of calculation, control, or communication, then these

42


mathematical engines of the 1940s were transformed to the networked information appliance
of the 1990s and focus expanded to a broader set of technologies and to the actual use of these
machines in insurance, finance, and government (Misa T., 2007). These machines have since
developed drastically including TPSs used today.

2.4 SECURITY RISKS ASSOCIATED WITH TPSs

According to Peralta A., (2004),

“Security is always a concern in a production database. In a TPS where logging in is
required, passwords will need to be authenticated to access the database. To start using a
system, a user provides a user identifier (user ID) and password to prove the user's
identity to the system; this process which can be automatic (and hidden from the user), is
known as authentication. After authenticating, users still need permission to access
system resources. The process of checking for permissions to access a resource is known
as authorization. “

Servers as well as clients should be authorised and authenticated to access the TPS; if these
measures are not established, malicious attacks where access to the database can be granted
to unauthorized persons and database can be attacked (this will question the integrity of the
DBMS) and IP spoofing where the TPS server can be used as a machine to carry out attacks on
other DBMSs. Figure 18 shows the sections in a TPS where the questions of security may arise.

Figure 18: Security points before access to DBMS

43


2.5 BUSINESS BENEFITS OF TPS
TPSs improves business operations; in the case of a retail company, sales of products increase,
transactions are faster and more organised than manual TPSs. Customer trends and high
demand products can be monitored in TPSs with inventory DBMSs. In recent times most
businesses and even individuals make use of TPSs to make payments, figure 19 and 20 show the
actual rise in the utilization of OLTPs and growth in business websites respectively.

Figure 19: Household access to internet (Source: http: //www. likencom425j1.wordpress.com)

Figure 20: Increase in websites (Source: http: //www. firstmonday.org)

44


Business benefits through TPSs can simply be acquired through customer satisfaction.
According to Graja H. and McManis J. (2001)
“A number of performance problems have been observed for E-commerce Web sites, and
much work has gone into characterising the performance of Web servers and Internet
applications. However, the customers of E-commerce websites are less well studied.”

Relating customer trace behaviour to the satisfaction vector can help note how customers can
be satisfied (Graja H. and McManis J., 2001). Satisfaction vectors include:
 Complexity: the less complex a website is, the more user-friendly it is.
 Time: this brings us back to the issue of response time.
 Quality: graphics at the user interface can attract customers to the website.

CHAPTER THREE: DESIGN, DEVELOPMENT AND IMPLEMENTATION

3.1 DESIGN AND STRUCTURAL INFORMATION
System design was instigated from reviewing the software requirement specification in
accordance with the prototyping approach to software development. Hasselbring W. (2000)
declares prototyping as a means to explore the essential features of a proposed system through
practical experimentation before its actual implementation to make the correct design choices
early in the process of software development. He also emphasized that prototyping concurrent
applications intend to bridge the gap between conceptual design of concurrent applications
and practical implementation on specific parallel and distributed systems. The first stage of this
software development model is requirement specification gathering followed by system design,
then prototype building; this involves the developing of a simple system which demonstrates all
requirement specification of the proposed system. Next stage is user evaluation; the outcome
of this stage helps make the decision to redesign prototype or go ahead and complete software
development.

45

Mc0914052 1

Recomendados

Recomendados

Más contenido relacionado

Similar a Mc0914052 1

Similar a Mc0914052 1 (20)

Mc0914052 1