Mc0914052 1
Upcoming SlideShare
Loading in...5
×
 

Mc0914052 1

on

  • 272 views

 

Statistics

Views

Total Views
272
Views on SlideShare
264
Embed Views
8

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 8

http://www.linkedin.com 8

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Mc0914052 1 Mc0914052 1 Document Transcript

  • DESIGN AND IMPLEMENTATION OF TRANSACTIONPROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS. BY OLUWAKEMI YERA 0914052 A DISSERTATION SUBMITTED IN PARTIAL FULFILMENT OF THEREQUIREMENTS 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
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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). 0914052 OLUWAKEMI YERA 3
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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. 0914052 OLUWAKEMI YERA 4
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS DEDICATION For Mum, I love you. 0914052 OLUWAKEMI YERA 5
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 0914052 OLUWAKEMI YERA 6
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 ADMINISTRATORS INTERFACE ........................................................................... 53 3.5.1.2 USERS 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 0914052 OLUWAKEMI YERA 7
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 0914052 OLUWAKEMI YERA 8
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 0914052 OLUWAKEMI YERA 9
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 0914052 OLUWAKEMI YERA 10
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 0914052 OLUWAKEMI YERA 11
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 0914052 OLUWAKEMI YERA 12
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 0914052 OLUWAKEMI YERA 13
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 0914052 OLUWAKEMI YERA 14
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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. 0914052 OLUWAKEMI YERA 15
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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. 0914052 OLUWAKEMI YERA 16
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 0914052 OLUWAKEMI YERA 17
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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. 0914052 OLUWAKEMI YERA 18
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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. 0914052 OLUWAKEMI YERA 19
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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. 0914052 OLUWAKEMI YERA 20
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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. 0914052 OLUWAKEMI YERA 21
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS  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 0914052 OLUWAKEMI YERA 22
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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) 0914052 OLUWAKEMI YERA 23
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 0914052 OLUWAKEMI YERA 24
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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). 0914052 OLUWAKEMI YERA 25
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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.” 0914052 OLUWAKEMI YERA 26
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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. 0914052 OLUWAKEMI YERA 27
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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). 0914052 OLUWAKEMI YERA 28
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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) STEP 1: STEP 2: STEP 3: 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. 0914052 OLUWAKEMI YERA 29
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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) STEP 1: STEP 2: STEP 3: 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- concurencyissues.html) 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). 0914052 OLUWAKEMI YERA 30
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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- concurencyissues.html) 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 wont 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 wont do that right because before commit new records may need to be processed, as well as few records may not exist. “ 0914052 OLUWAKEMI YERA 31
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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) 0914052 OLUWAKEMI YERA 32
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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) 0914052 OLUWAKEMI YERA 33
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 customers 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 customers last order (TPC Benchmark revision 5.11, 2010). This business transaction facility is also not available on Hullfate’s TPS. 0914052 OLUWAKEMI YERA 34
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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. 0914052 OLUWAKEMI YERA 35
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 0914052 OLUWAKEMI YERA 36
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS  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. 0914052 OLUWAKEMI YERA 37
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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. 0914052 OLUWAKEMI YERA 38
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS User Module DBMS PRESENTATION APPLICATION FACILITY FACILITY TRANSACTION DATA DATABASE SUPPORT ACCESS PRESENTATION APPLICATION 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 0914052 OLUWAKEMI YERA 39
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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) 0914052 OLUWAKEMI YERA 40
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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). 0914052 OLUWAKEMI YERA 41
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Centralised system PRESENTATION APPLICATION 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 0914052 OLUWAKEMI YERA 42
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 users 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 0914052 OLUWAKEMI YERA 43
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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) 0914052 OLUWAKEMI YERA 44
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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. 0914052 OLUWAKEMI YERA 45
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Start Requirement Design Building gathering prototype S top Engineer Refining User evaluation product prototype Figure 21: Prototyping Approach to Software Development (Source: http://www.freetutes.com/systemanalysis/sa2- prototyping-model.html) 3.2 REQUIREMENTS SPECIFICATION For this system to function as required the following aspects are expected:  Website should allow multiple browsing of products and other associated web pages.  Users will not need to register in order to browse through the website or purchase items.  System should allow for product acquisition.  System should confirm the number of products acquired.  The system should also inform user if product acquisition is successful or otherwise.  Administrative maintenance and change of system information should be allowed A three-tier application structure is the basis of this system. The structure comprises:  The presentation level which comprises the graphic user interface (GUI) level through which users query the database. This might be personal computers or mobile devices.  Database level where storage of the company data, recovery of data and database management occurs. SQL Buddy, a free service offered by the web hosting company, Zymic represents the database level in our transaction processing system.  Business web server level which serves as a moderator between the presentation level (GUI) and the database (SQL buddy); this free service is also offered by Zymic. 0914052 OLUWAKEMI YERA 46
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS DBMS Database (PCs, Users, (Web server) (Database server) Mobile device) CLIENT TIER WEB TIER DBMS TIER DATABASE TIER ENCLOSES ENCLOSES ENCLOSES DATABASE SERVER PRESENTATION APPLICATION SERVER SERVER Figure 22: Three tier system structure Figure 23: Free web hosting site, Zymic.com 0914052 OLUWAKEMI YERA 47
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 3.3 ACTIVITY DIAGRAM The system activity diagram below shows the workflow of the activities of all users including clients and administrators. It also illustrates the rational queries by users for purchase of products on the website and how the system responds to these queries. open <<datastore>> check product purchase website user requirement User must meet product purchase requirement USER Accumulate product purchase Deny details access Confirm in less Check product than 5 seconds purchase details User access decision Deny Allow user to purchase access products SYSTEM <<datastore>> update Figure 24: Case study TPS activity diagram 0914052 OLUWAKEMI YERA 48
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 3.4 USE CASE The featured use case is presented as a means to depict system and user interaction especially focusing on the system functionality. Users and administrators are the main participants for this system.  Users: can access, browse the website and purchase product. Users do not need to register or login before access to the website is granted.  Administrator: manages system database, adds new products, edits product details and updates product availability. Product Administrator User purchasing s system Administrator Search for Search access User product product access price Receive confirmation Purchase product <<include>> <<extend>> Figure 25: Use case diagram for our case study TPS 0914052 OLUWAKEMI YERA 49
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 3.5 SYSTEM IMPLEMENTATION In this section, we are going to look at the implementation of system, the development process and development environment. The system was developed using PHP and HTML scripting language, the database was created on PhpMyAdmin using MySQL query language; PhpMyAdmin and MySQL came as a package on software called XAMPP provided by The Apache Software Foundation (ASF) a non-profit corporation, incorporated in Delaware, USA, in June of 1999. The ASF is a natural outgrowth of The Apache Group, a group of individuals that was initially formed in 1995 to develop the Apache HTTP Server (http://www.apache.org/foundation/faq.html#what). XAMPP provides the ability to use the personal computer as a local host and test the functionalities of the website before deployment on the World Wide Web. Adobe Dreamweaver CS5 was also used in the design; this software offers a split screen feature where the actual webpage can be viewed on one screen as it is being written in codes on the other screen. Figure 26: Split screen feature of Adobe Dreamweaver CS5 0914052 OLUWAKEMI YERA 50
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Each web page was developed as described earlier and linked to the home page so that they can be viewed from the navigation pane on the home page. Figure 27 shows Hullfate’s web pages and their functions. Stores the Details product template for all sections and pages web navigation pane Purchase of products can be done on this page USER ACCESS INDEX PAGE Purchase confirmation Clients can access HOME PAGE the website, authentication is not required PRODUCTS PAGE CONFIRMATION PAGE Details how PAYMENT OPTION payments can be made HELP Help page Company history ABOUT US and details Details how company CONTACT US can be contacted Figure 27: Website pages and summary of their functions 0914052 OLUWAKEMI YERA 51
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 3.5.1 FRONT END User interface (UI) exhibits the web pages and allows users to interact with the database. Created using PHP and HTML codes and edited on Adobe Dreamweaver CS5, the six main web pages can be accessed using the navigation pane on the left hand side of the home page. Also used is the Cascading Style Sheets (CSS) available from Adobe Dreamweaver CS5. Figure 28: Hullfate Direct home page Users can browse different product categories from the home page shown in Figure 28. Product can be purchased from the ‘Products’ page and company information obtained from the ‘About Us’ and ‘Contact Us ’pages. 0914052 OLUWAKEMI YERA 52
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 3.5.1.1 ADMINISTRATORS INTERFACE Before deployment on the World Wide Web, updates and changes can be made to the web pages using Adobe Dreamweaver via editing the PHP and HTML codes used in developing the pages. The database can be updated using MySQL on PhpMyAdmin; changes can be made to all tables on the database. Figure 29: Editing Web Pages via Adobe Dreamweaver 0914052 OLUWAKEMI YERA 53
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 30: Editing database using MySQL on PhpMyAdmin After deployment on the World Wide Web, updates and editing is carried out directly on the web hosting facility ‘File Manager’ provided for these functions and on databases facility ‘SQL Buddy’ using MySQL queries. Figure 31: Facility for editing web page codes on the web hosting site 0914052 OLUWAKEMI YERA 54
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 32: Facility for updating database on the web hosting site 3.5.1.2 USERS INTERFACE Users access the website through the home page and interested customers can purchase products via the ‘Products’ page. Other web pages can also be accessed through the navigation pane on the home page. 0914052 OLUWAKEMI YERA 55
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 33: Products page 3.5.2 BACK END DATABASE Ability of a database to satisfy data integrity notwithstanding the pressure of concurrent user queries requires a high-tech database storing facility that can deliver results with minimum transaction failures. The database storing facility used in this project is PhpMyAdmin for the prototype development and SQL Buddy on the web hosting server. These facilities ensure the integrity of data by enabling database management, allowing coding and editing of PHP files. Nevertheless, a connection was required to PHP files (webpage codes) for optimum user access and database updates in accordance to user queries. Fig 34 shows the database connection code used in this regard and figure 35 illustrates connection code for ‘Products’ page to database. 0914052 OLUWAKEMI YERA 56
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS <?php $dbc = mysql_connect (localhost,root, ); if (!$dbc) { die(Not connected : . mysql_error()); } $db_selected = mysql_select_db("hullfate", $dbc); if (!$db_selected) { die("Cant connect :" . mysql_error()) ; } ?> Figure 34: Database connection code <?php mysql_connect("localhost", "root", "") or die(mysql_error()); mysql_select_db("hullfate") or die(mysql_error()); $qty = $_POST[quantity]; $id =$_POST[productID]; $query = mysql_query("select * from stock where productID =".$id); $result = $query; $row = mysql_fetch_array($result); $a = $row[stockQUANTITY]; $b = $row[stockID]; if($a>$qty) { $c = $a - $qty; mysql_query("update stock set stockQUANTITY = ".$c." where stockID = ".$b); echo "<h1>You have ordered " .$qty. " items. </h1><br/>"; echo "<h1>Thanks for shopping with Hullfate Direct.</h2>"; } else { echo "Item out of stock."; } ?> Figure 35: PHP code connecting the ‘Products’ page queries to inventory DBMS 0914052 OLUWAKEMI YERA 57
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS There were three tables created in the database namely PRODUCTS, STOCK AND COLLABORATION. Products table consisting of the productID, productNAME, productDESC, productPRICE, and picturePATH columns stores the product information. All tables in the database have primary keys; the product table’s primary key is the productID. Reasonable normalisation of the tables was ensured and relationship between the tables was established using foreign and primary keys. CREATE TABLE `hullfate`.`product` ( `productID` INT( 10 ) NOT NULL , `productNAME` VARCHAR( 50 ) NOT NULL , `productDESC` VARCHAR( 100) NOT NULL , `productPRICE` FLOAT( 6, 2 ) NOT NULL , `picturePATH` VARCHAR( 100 ) NOT NULL ) ENGINE = INNODB ; Figure 36: SQL query used to create the PRODUCTS table in the database hullfate.collaboration hullfate.stock collaborationID : int (10) PK stockID : int (10) PK productID : int (10) FK productID : int (10) FK customerID : int (10) stockQUANTITY : int (10) Status : int (2) hullfate.product productID: int (10) PK productNAME: varchar (50) productDESC: varchar (100) productPRICE: float (6,2) picturePRICE : varchar (100) Figure 37: Application database diagram 0914052 OLUWAKEMI YERA 58
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 3.5.2 PROBLEMS ENCOUNTERED Limitations were met by the researcher in investigating this study, despite the extensive educational materials available. The scripting languages utilized in developing the web pages were self taught by the researcher so as to produce a modern and up to date TPS consisting of a dynamic e-commerce website connected to an inventory DBMS. Comprehensive investigation could not be done due to time limitations. Initially, the use of HP Loadrunner was planned to be used to automate the performance testing on our TPS as thousands of virtual users can be generated to access the system concurrently but problems were encountered downloading this software and the researcher utilized a free load testing software, Web Performer Load Tester which only allowed the use of ten virtual users. A payment system from PayPal was incorporated into the website to handle the payment for products and was originally supposed to be part of the system which is to be tested but problems were envisaged as the researcher could not obtain dummy credit/ debit cards. CHAPTER FOUR: TESTING 4.1 TESTING TECHNIQUE Since this project is based mainly on the analysis of the performance of our case study retail company (Hullfate Direct) transaction processing system (hullfate.99k.org) when concurrently accessed, the use of Web Performer Load Tester 4.1 is being employed in the testing process. Load Tester allows the deployment of multiple concurrent virtual users to access the case study TPS (website). Making use of various computers and human attendance will not be logical in this testing plan. Testing process is extensively explained in section 4.3. Software testing validates and verifies that the software developed meets specified requirements. Software testing methodologies used in this project are black box and white box software testing. Black box testing basically focuses on testing the functionality of the software and not the codes used in developing the software while white box testing focuses on the functionality of the codes. 0914052 OLUWAKEMI YERA 59
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Requirements Input Output Executable program Events Black Box testing Figure 38: Black box testing illustrated Statement or unit testing White box Decision testing testing Condition testing Figure 39: White box testing 4.1.1 INTRODUCING WEB PERFORMER LOAD TESTER 4.1 Load Tester is business optimization software that simulates real life business scenarios in software application performance testing which includes an analysis module (Analyzer) and a load testing module (Load Tester). This software, used to automate load and stress testing 0914052 OLUWAKEMI YERA 60
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS before applications are deployed, helps discover system performance failures. The version being used in this study is the latest version released on June, 2010. Figure 40: Load Tester architecture (Source: http://www.webperformanceinc.com/library/whitepapers/CNAV/systemdiag.jpg) 4.2 TEST STRATEGY User and unit testing will be performed and results displayed in the appendices while system performance testing technique and process will be discussed in this section. Table 7 shows the testing techniques and processes performed on the system. 0914052 OLUWAKEMI YERA 61
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Techniques Tests Location Tested Features Resources Black box testing User acceptance test Frontend Button functionality Website Hyperlinks Website Backend Data integrity checks Database Data consistency Database Performance testing Website Response time Load Tester Website Concurrent accessibility Load tester Website Transactional mix Website Database Load Tester Load Tester White box testing Unit Testing Codes Websites Database Table 7: Test strategy illustrated Frontend test validates and verifies the user interface; testing process includes input validation checks and button functionality checks. Backend test validates and verifies database functionality and its operations; process includes data integrity check to ensure data consistency in database. Performance test checks the performance of the website under concurrent access; process included checking response time, concurrent accessibility and transactional mix amongst other processes. 4.3 PERFORMANCE TEST As earlier mentioned in section 2.1.6, aspects to be monitored in this section are features that are important to improve business operations for Hullfate Direct and they are as follows: 0914052 OLUWAKEMI YERA 62
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS  Response time: 90th percentile response time has to be more than 25 seconds for the systems transaction (transaction mix). 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 8: Expected response time for new order and stock level transactions  Concurrent accessibility: More than one user should be able to access the website. Ten virtual users were generated by Load tester to carry out this testing. Load Test Report 11/09/10 21:31 Load Configuration [1] Estimated User Capacity undetermined less than 10 Maximum Users Analyzed 10 Goals Analyzed Total 10 - Pages 9 - Transactions 0 - Test 1 Table 9: Load configuration before testing  Transactional mix: Transactional mix is the total time it takes a user to perform a transaction. For Hullfate, a transaction will be ordering a product and transaction mix will be new order and stock level as explained in section 2.1.6. 0914052 OLUWAKEMI YERA 63
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 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 10: Minimum transaction mix percentage for new order and stock level 4.4 DEVELOPING PERFORMANCE TEST CASE A test case in Load Tester is a record of interaction between the user and the website via the browser. Test cases can be played back to make sure the steps emulate a real user, it can also be customized to suite preferences. The test case includes a scenario, in the case of our website; the user browses through the web pages and finally purchases a product on the product page. The recorded test cases develop page metrics that should be met when the website is under test. Our test case is to purchase an item from the website. Page Metrics Title Duration Size Status # Page Think URLs Size time Hullfate Direct [1] 3.037 94.4 KB 200 3 3.1 KB 2.397 Hullfate Direct [2] 1.516 31.6 KB 200 6 4.6 KB 1.888 Hullfate Direct [3] 1.359 38.5 KB 200 6 13.0 KB 1.683 Hullfate Direct [4] .327 3.8 KB 200 1 3.8 KB 2.967 Hullfate Direct [5] .265 4.1 KB 200 1 4.1 KB 2.607 Hullfate Direct [6] .216 4.7 KB 200 1 4.7 KB 2.088 Hullfate Direct [7] .238 3.7 KB 200 1 3.7 KB 3.004 Hullfate Direct [8] .548 13.0 KB 200 1 13.0 KB 15.476 Hullfate Direct [9] .263 3.5 KB 200 1 3.5 KB .000 Table 11: The page section contains metrics for each web page in the test case 0914052 OLUWAKEMI YERA 64
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS These recorded test cases then generate performance goals for the website to meet during testing. Page Performance Goals Page Duration Size Failed Goals (as recorded) Hullfate Direct [1] 3.037 94.4 KB Hullfate Direct [2] 1.516 31.6 KB Hullfate Direct [3] 1.359 38.5 KB Hullfate Direct [4] .327 3.8 KB Hullfate Direct [5] .265 4.1 KB Hullfate Direct [6] .216 4.7 KB Hullfate Direct [7] .238 3.7 KB Hullfate Direct [8] .548 13.0 KB Hullfate Direct [9] .263 3.5 KB Table 12: The goals section shows the state of performance goals configured for pages in the test case Testcase Report hullfate load test 2 Summary Summary information about the testcase. Total Duration 39.87 Pages 9 URLs 21 Images 11 Total size 197.3 KB Table 13: Test case information 0914052 OLUWAKEMI YERA 65
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 41: Test case Figure 43 shows test case generated by Load Tester illustrating total time to load all URLs as 7.769 minutes, think times, total web pages and URLs accessed. 4.5 DEVELOPING PERFORMANCE TEST (LOAD) CONFIGURATIONS Figure 43 explains configuration for testing. The number of virtual users was determined adding one user every two minutes; this process is called ramping up, then the test was set to run for twenty minutes and ramping down set to be random. 0914052 OLUWAKEMI YERA 66
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 42: Web Performer configuration for test case Load Configuration Duration 20 minutes Start Users 10 Increment Users 1 users over 2 minutes every 60 minutes Limit To n/a Estimated Peak Users 10 Table 14: Load configuration 0914052 OLUWAKEMI YERA 67
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 4.6 RUNNING PERFORMANCE TEST Testing occurred for twenty five minutes while snapshots of testing intervals were taken. MQTh Ramp up Steady state Ramp down Measurement interval start Measurement interval end Elapsed time (sec.) Figure 43: Illustration of ramping up and down and interval where data should be collected (TPC, 2010). Figure 44: Test at 1.15 minutes; illustrates ramping up 0914052 OLUWAKEMI YERA 68
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 45: Test at 5.02 minutes when all virtual users have accessed the website Figure 46: Test at 22.40 minutes; ramping down 0914052 OLUWAKEMI YERA 69
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS CHAPTER FIVE: ANALYSIS AND DISCUSSION OF FINDINGS 5.1 RESPONSE TIME URLs for page: Hullfate Direct [1] Title Duration Total Status Request Response Request Response TTFB size Size Size Duration Duration Hullfate Direct [1] .261 3.1 KB 200 526 B 2.6 KB .001 .001 .260 twoColLiqLtHdr.css .444 7.7 KB 200 368 B 7.3 KB .001 .007 .437 cooltext466688049.png 1.915 83.6 KB 200 374 B 83.2 KB .001 1.486 .429 URLs for page: Hullfate Direct [2] Hullfate Direct [2] .420 4.6 KB 200 586 B 4.0 KB .001 .001 .419 safetyboots1.jpg .235 4.2 KB 200 390 B 3.8 KB .001 .001 .234 cones.jpg .261 4.6 KB 200 383 B 4.3 KB .001 .001 .260 firstaidkit.jpg .420 5.2 KB 200 389 B 4.8 KB .001 .001 .419 safetysign.jpg .435 8.0 KB 200 388 B 7.6 KB .001 .007 .428 safetyjacket.jpg .864 5.0 KB 200 390 B 4.6 KB .001 .001 .863 URLs for page: Hullfate Direct [3] Hullfate Direct [3] .609 13.0 KB 200 611 B 12.4 KB .001 .180 .429 visor1.jpg .224 4.4 KB 200 388 B 4.0 KB .001 .001 .223 gloves.jpg .320 3.9 KB 200 388 B 3.5 KB .001 .001 .319 safetyhat.jpg .470 5.4 KB 200 391 B 5.0 KB .000 .001 .469 kneepads1.jpg .474 5.7 KB 200 391 B 5.3 KB .001 .001 .473 safetyjacket1.jpg .507 6.2 KB 200 395 B 5.8 KB .001 .014 .493 URLs for page: Hullfate Direct [4] Hullfate Direct [4] .327 3.8 KB 200 621 B 3.2 KB .001 .001 .326 URLs for page: Hullfate Direct [5] Hullfate Direct [5] .265 4.1 KB 200 617 B 3.5 KB .000 .001 .264 URLs for page: Hullfate Direct [6] Hullfate Direct [6] .216 4.7 KB 200 610 B 4.1 KB .001 .001 .215 URLs for page: Hullfate Direct [7] Hullfate Direct [7] .238 3.7 KB 200 615 B 3.1 KB .001 .001 .237 URLs for page: Hullfate Direct [8] Hullfate Direct [8] .548 13.0 KB 200 616 B 12.4 KB .001 .196 .352 URLs for page: Hullfate Direct [9] Hullfate Direct [9] .263 3.5 KB 200 753 B 2.7 KB .001 .001 .262 Table 15: Test metrics 0914052 OLUWAKEMI YERA 70
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Regarding the 10 seconds response time a system should meet proposed by IBM Information Centre (2010) discussed previously in the introductory part of this document, it is very clear that our system has passed since the highest response time did not exceed 1.486 seconds. And according to the TPC, 90th percentile of New order should not exceed 5 seconds and 90th percentile stock level should not exceed 20 seconds. As observed in table 15 our new order section of the transaction mix are Hullfate Direct [1], [2] and [3] which when their response time was computed came to 1.713 seconds with 90th percentile of 1.541 seconds. And the stock level which is Hullfate Direct [9] has a response time of 0.01 and 90th percentile of 0.009 seconds. 5.2 CONCURRENT ACCESSIBILITY Figure 47: Ramping up, steady access and ramping down of the ten virtual users used From figure 47, it can be confirmed that ten virtual users accessed the system and where able to make transactions (access web pages); this confirmation supports the fact that the system has passed this test of concurrent accessibility. 0914052 OLUWAKEMI YERA 71
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 5.3 TRANSACTION MIX According to TPC benchmark illustrated in section 4.3, there is no constraint on the percentage the new order transaction should entail in the total transaction mix; nevertheless stock level transaction should encompass 4% of total transaction mix. Stock level in our system test is Hullfate direct [9] as illustrated in table 16 which has a total of 0.263 seconds in duration. The total transaction mix is 7.769 seconds; therefore our stock level is 3.38% of the total transaction mix. URLs for page: Hullfate Direct [9] Title Duration Total Status Request Response Request Response TTFB size Size Size Duration Duration Hullfate Direct [9] .263 3.5 KB 200 753 B 2.7 KB .001 .001 .262 Table 16: Stock level transaction of Hullfates website 5.4 OTHER FINDINGS The following results were not part of our test case but they play important roles in allowing the understandings of the capabilities of the system being developed. 5.4.1 WAITING USERS AND AVERAGE WAIT TIME The Waiting Users and Average Wait Time metrics help diagnose certain types of performance problems related to the server (Web Performance Load Tester, 2010). For example, they can help determine what pages users have stopped on when a server becomes non-responsive (Web Performance Load Tester, 2010). The Waiting Users metric counts the number of users waiting to complete the item at the end of the sample period (Web Performance Load Tester, 2010). The Average Wait Time describes the amount of time, on average, that each of those users has been waiting (Web Performance Load Tester, 2010). 0914052 OLUWAKEMI YERA 72
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 48: Waiting users 5.4.2 PAGE DURATION It can be observed that all page durations exceeded the page duration goal during the test. Figure 49: Page duration 0914052 OLUWAKEMI YERA 73
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 5.4.3 FAILURES The failure goal set at zero percent was exceeded somewhere around the fifth minute mark Figure 50: Failures CHAPTER SIX: CONCLUSION AND RECOMMENDATION 6.1 CONCLUSION This whole project has analysed a modern means of developing dynamic website for a TPS, developed an Online Transaction Processing System, tested the system for basic usability and analysed the performance of the system under concurrent access. The decision to develop the system in this manner is as a result of the uncomplicated accessibility to the software utilised and the ability of easy update operations available for the system. The developed system meets the requirement specification specified at the beginning of the project and has potentials for improvement. The ultimate capabilities of our e-commerce website could not be totally assessed due to the limitation of virtual users but notwithstanding the concurrent accessibility of the system was able to be established. 0914052 OLUWAKEMI YERA 74
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS 6.2 RECOMMENDATION FOR FUTURE RESEARCH System performance testing with complete and advanced technology like Hewlett Packard Loadrunner could be utilized to comprehend the full potentials of the system. Payment and delivery components should be added to allow for full e-commerce fictionalisations of the system. With the payment component comes the issue of payment security, secure (https) pages should be incorporated to ensure clients can make payments securely. 0914052 OLUWAKEMI YERA 75
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS REFERENCES  Aybay I. And Halici U. (1995), ‘Concurrency Control In Distributed Database Systems’. Lecture notes on Operating Systems, Dept of EE Eng., Middle East Technical University, Ankara. Available at: http://www.eee.metu.edu.tr/~vision/LectureNotes/EE442/Ee442ch7.html. (Accessed: 5 July, 2010).  Bernstein A. and Newcomer E. (2009), Principles of Transaction Processing Systems, 2nd ed. Morgan Kaufman (Burlington, USA).  Bernstein P. And Goodman N. (1981) ’Concurrency Control in Distributed Database Systems’ Journal of the Association of Computing Machinery, 13(2). EBSCOhost [Online] Available at: http://0-search.ebscohost.com.brum.beds.ac.uk (Accessed: 23 June, 2010).  Bhargava B. (1999), ‘Concurrency controls In Database Systems’ IEEE Transactions on Knowledge and Data Engineering, 11(1) pp.3-16. [Online] Available at: http://www.cs.purdue.edu/homes/bb/cs542-06Spr-bb/cc.pdf (Accessed: 18 June, 2010).  Date C. J. (1995), An Introduction To Database Systems, 5th ed. Addison-Wesley.  Dougherty E. And Laplante P. (1995), Introduction to Real-Time Imaging, Wiley-IEEE Press.  Elmasri and Navathe (2000), Fundamentals of Database Systems Addison, 3rd ed. Wesley Longman, Inc.  Graja H. and McManis J. (2001), ‘Quantifying Customer Satisfaction with E-Commerce Websites’ In Proceedings of the 17th IEE UK Teletraffic Symposium. [Online]. Available at: http://www.webperformanceinc.com/library/files/UKTT17.pdf (Accessed: 1 September, 2010).  Gray, J.N. And Reuter, A. (1992). Transaction Processing: Concepts and Facilities. Morgan- Kaufmann, San Mateo, CA.  Guohong C. (2005), ‘Mutual Exclusion & Concurrency Control’ Distributed Systems. [Online]. Available at: http://www.cse.psu.edu/~gcao/teach/513/ch3.pdf (Accessed: 16 August, 2010).  Hasselbring W. (2000), ‘Programming Languages and Systems for Prototyping Concurrent Applications’ Journal of Association for Computing Machinery, 32(1), pp 43-79. EBSCOhost [Online] Available at: http://0-search.ebscohost.com.brum.beds.ac.uk (Accessed: 16 August, 2010). 0914052 OLUWAKEMI YERA 76
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS  Ho M. (2000), Transaction management, [Online] Available at: http://personal.cityu.edu.hk/~ismikeho/dm2/dmchap9.htm (Accessed: 21 June 2010).  Hong C. (2005) ‘Study on Performance Anomaly in Clustered On-line Transaction Processing Systems’. Unpublished PhD Thesis. University of Tsukubu. [Online] Available at: http://www.is.tsukuba.ac.jp/H16Syuron/200005577.pdf (Accessed: 16 June, 2010).  IBM (2010), ‘CICS Transaction Processing’, Understanding TXSeries for Multiplatforms. [Online] Available at: http://publib.boulder.ibm.com/infocenter/txformp/v6r0m0/index.jsp?topic=/com.ibm.cics. te.doc/erziaz0016.htm (Accessed: 22 July, 2010).  Kehtarnavaz N. And Gamadia M. (2006), Real-Time Image and Video Processing: From Research to Reality. Morgan & Claypool. [Online] Available at: http://vada.skku.ac.kr/crazy/cwb-data/data/lecarch/real-time-dsp.pdf (Accessed: 18 June, 2010).  Kok D. And Wesson J. (2002), ‘Designing Transaction Processing Systems: A Patterns Approach’ Proceedings of SAICSIT 2002. [Online] Available at: (Accessed: 14 August, 2010).  Laudon J.C. and Laudon J.P. (2002) Management Information Systems: Managing the Digital Firm, 7th ed. Prentice-Hall, Englewood Cliffs, NJ.  Misa T. (2007), ‘Understanding How Computing Has Changed the World’’ IEEE Annals of the History of Computing. [Online] Available at: http://0- search.ebscohost.com.brum.beds.ac.uk (Accessed: 30 August, 2010).  Papadimitriou C. (1979), ‘Serialisability of Concurrent database Updates’ Journal of the Association for Computing Machinery. 26(4) pp.631-653. EBSCOhost [Online] Available at: http://0-search.ebscohost.com.brum.beds.ac.uk (Accessed: 19 July, 2010).  Powers, G. K. (2000) Heinemann information processes and technology. Harcourt Education Australia.  Peralta A. (2004), Principles of Database Management Systems. Available at: http://aurelie.prepys.com/2008/08/14/database-dbms-principles-and-the-relational- model/. (Accessed: 23 June, 2010).  Przemyslaw C. (2010), Concurrency Issues. Available at: http://www.sql-sys.com/sql-server- resources/transactions/17-concurencyissues.html . (Accessed: 19 June, 2010 ) 0914052 OLUWAKEMI YERA 77
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS  Radu G. (2005), Architecture of Transaction Processing Systems, Computer Science Department Stony Brook University. Available at: http://www.cs.sunysb.edu/~liu/cse315/23.pdf.  Singhal and Shivaratri (1994). Advanced operating Systems, McGraw-Hill Inc., USA.  Sivasankaran M. et al (1995), "Priority assignment in real-time active databases", The VLDB Journal, 5:19–34, [Online] Available at: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=331718 (Accessed: 18 June, 2010).  Thomasian A. (1998) ‘Distributed Optimistic Concurrency Control Methods for High- Performance Transaction Processing’ IEEE transactions on knowledge and data engineering, 10(1), pp.173-189. [Online]. Available at: http://www.cs.ucdavis.edu/~wu/ecs251/ecs251_DOCC.pdf (Accessed: 16 June, 2010).  Transaction Processing Performance Council (2010), TPC Benchmark Standard Specification Revision 5.11. [Online]. Accessed at: http://www.tpc.org/tpcc/spec/tpcc_current.pdf (Accessed: 25 August, 2010).  Web Performer Load Tester (2010), Load Tests. Available at: http://www.webperformanceinc.com/load_testing/reports/loadtestreport. (Accessed: 7, September, 2010)  Yu et al (1993) ‘On the Analytical Modelling of Database Concurrency Control’ Journal of the Association of Computing Machinery, 40(4), pp 83 1–872. EBSCOhost [Online] Available at: http://0-search.ebscohost.com.brum.beds.ac.uk (Accessed: 16 July, 2010). 0914052 OLUWAKEMI YERA 78
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS APPENDICES APPENDIX A: SCREEN SHOTS OF WEB PAGES Figure 51: Home Page Figure 52: Products page 0914052 OLUWAKEMI YERA 79
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 53: Confirmation Page Figure 54: Help Page 0914052 OLUWAKEMI YERA 80
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS APPENDIX B: SCREEN SHOTS OF DATABASE Figure 55: Complete database showing the three tables on PhpMyAdmin Figure 56: Collaboration table on PhpMyAdmin 0914052 OLUWAKEMI YERA 81
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 57: Products table on PhpMyAdmin Figure 58: Stock table on PhpMyAdmin 0914052 OLUWAKEMI YERA 82
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 59: Database on SQL Buddy Figure 60: Products Table on SQL Buddy 0914052 OLUWAKEMI YERA 83
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 61: Stock table on SQL Buddy Figure 62: Collaboration table on SQL Buddy 0914052 OLUWAKEMI YERA 84
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS APPENDIX C: PROJECT SUMMARY, NETWORK FLOW DIAGRAM, COMPLETED TASKS AND GANTT CHART. Figure 63: Project summary 0914052 OLUWAKEMI YERA 85
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Page 1 Page 2 0914052 OLUWAKEMI YERA 86
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 64: Completed tasks Figure 65: Gantt chart A 0914052 OLUWAKEMI YERA 87
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS Figure 66: Gantt chart B 0914052 OLUWAKEMI YERA 88
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS APPENDIX D: PRODUCT BREAKDOWN STRUCTURE TRANSACTION PROCESSING SYSTEM FRONTEND BACKEND PROJECT MANAGEMENT PRODUCTS USER ADMIN DATABASE PROJECT PROJECT COMMU- RISKS/ INTERFACE WED TABLES SCHEDULE NICATION ISSUES PLAN INTERFACE PLAN LOGS PHP PHP DATABASE PROJECT GANTT MEETING RISK CONTROLS CONTROLS APPROVAL MINUTES CHART LOGS AND START UP PHP NAVIGATION MYSQL PROJECT E-MAIL ISSUE CODES MAPS PROPOSAL LOGS ACTIVITY E-R PROJECT DIAGRAM MANDATE MODEL ACTIVITY NETWORK PRODUCT DIAGRAM BREAKDOWN FLOW DIAGRAM STRUCTURE 0914052 OLUWAKEMI YERA 89
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS APPENDIX E: TEST RESULTSTests Tested Features Expected Result Actual ResultUser Button functionality Should carry out expected purpose Passedacceptance test Hyperlinks Should forward to required web page Passed Data integrity checks Proliferation of updates should occur across Passed all associated tables in the database Data consistency PassedTests Tested Features Expected Result Actual ResultPerformance Response time Passedtesting Concurrent Passed accessibility Transactional mix PassedTests Tested Features Expected Result Actual ResultUnit Testing Codes Conduct actions they are designed to do Passed 0914052 OLUWAKEMI YERA 90
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS APPENDIX F: OVERALL SYSTEM PERFORMANCE TEST RESULTS PAGE DURATION PAGE COMPLETION RATE 0914052 OLUWAKEMI YERA 91
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS TRANSACTION (URL) COMPLETION RATE FAILURES 0914052 OLUWAKEMI YERA 92
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS BANDWIDTH CONSUMPTION CASES/MINUTE 0914052 OLUWAKEMI YERA 93
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS WAITING USERS 0914052 OLUWAKEMI YERA 94
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESSElapsed "Page "Min "Avg "Max "Average time "Users" "Pages/ Failure "Hits/ "Bandwidth Page Page Page "Waiting Wait (ms) sec" Rate" sec" Out" Dur Dur Dur (ms)" Users" Time" (ms)" (ms)"10000 1 0 0.2 5984 1 796020000 2 0.2 0 0.7 6542 5942 7556 9171 1 18930000 4 0 0.5 13525 4 726740000 5 0.1 0 0.7 8058 16029 16029 16029 5 1063450000 6 0.2 0 1 14737 7607 8631 9655 6 1482260000 7 0.2 0 1.4 7805 4604 17035 29466 7 1654070000 8 0.3 0 0.4 8418 9157 23793 40910 7 1569880000 8 0.6 0 2.3 14330 2304 10203 22381 5 2339990000 8 0.6 0 0.6 2968 609 4354 14099 7 21827100000 9 0.1 0 1.2 9148 3773 3773 3773 8 28183110000 10 0.2 0 0.3 9887 12472 19239 26007 9 29369120000 10 0.7 0 0.8 4305 959 19893 74862 10 20354130000 10 1 0 2.8 21046 1893 10732 51965 8 21529140000 10 0.5 0 1.2 17722 3480 11242 24219 7 27818150000 10 0.2 0 0.9 7130 3379 10156 16933 9 28821160000 10 0.8 0 2.4 13343 3595 12872 27945 9 26300170000 10 0.8 0 1.4 15355 669 7568 26545 5 50032180000 10 0.8 0 1.3 5943 1432 4079 7272 6 49265190000 10 0.3 0 0.5 4489 1757 4273 7559 9 41021200000 10 0.1 0 0.1 1558 8810 8810 8810 8 55699210000 10 0.3 0 1 7405 1438 28341 56393 8 55709220000 10 0.1 0 0.5 2442 1460 1460 1460 10 54081230000 10 0.2 0 0.3 3043 49427 127477 205527 8 47970240000 10 0 0.2 971 10 48179250000 10 0.1 0 0.5 2559 30546 30546 30546 10 54935260000 10 0 0.1 1335 10 64934270000 10 0.2 0.6667 0.3 2772 31812 42450 53088 10 65814280000 10 0.3 0 0.3 3271 1391 48405 95396 8 76208290000 10 0.2 0 0.3 3282 4554 45058 85563 8 76405300000 10 0.1 0 0.5 3305 30740 30740 30740 8 83585310000 10 0.3 0 2 11189 7646 28901 62542 9 74977320000 10 0.4 0 1.4 5913 611 5428 16578 9 82704330000 10 0.5 0 1.2 15085 903 11854 39376 10 77097340000 10 0.4 0 0.7 2961 591 11320 22650 8 101991350000 10 0.2 0 0.6 3485 10065 86230 162395 7 103365360000 10 0.7 0 1.7 9614 500 23034 145046 9 70918370000 10 0.8 0 1.1 6215 462 27632 205262 8 61409380000 10 0.7 0 0.8 10449 998 16760 49176 8 56112390000 10 0.5 0 0.5 9133 431 8145 27017 7 69650400000 10 0.5 0 1.3 9746 1732 6535 11634 7 77174410000 10 0.4 0 1.4 15007 2611 10677 24860 6 94332420000 10 0.4 0 0.6 2811 707 8635 18296 8 75382 Table 17: Test report metrics 0914052 OLUWAKEMI YERA 95
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS APPENDIX G: USER MANUAL1. Open web browser and type URL: http://www.hullfate.99k.org2. Navigate through the website using the navigation pane on the left hand side of the pagewhen the website opens.3. Clicking on the ‘Home’ tab will redirect you to the home page 0914052 OLUWAKEMI YERA 96
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS4. Clicking on the ‘Products’ tab will redirect you to the products page where you can purchase products.5. Clicking the purchase button will confirm the number of products you have ordered. 0914052 OLUWAKEMI YERA 97
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS6. Or if the product is not available. 0914052 OLUWAKEMI YERA 98
  • DESIGN AND IMPLEMENTATION OF TRANSACTION PROCESSING SYSTEM AND ANALYSIS OF ITS PERFORMANCE UNDER CONCURRENT ACCESS APPENDIX H: THESIS POSTER 0914052 OLUWAKEMI YERA 99