Mc0914052 1

390 views
310 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
390
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Mc0914052 1

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 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 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
  29. 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) 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
  30. 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 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. 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

×