Blog entry by HENDRO EKO PRABOWO 5116201006

Anyone in the world

Transaction processing (TP) systems are designed to process user requests for information from a database, or requests to update a database (Lewis et al., 2003). Technically, a database transaction is sequence of operations that is treated as a single unit (an atomic unit). All of the operations in a 
transaction have to be completed before the database changes are made permanent. This ensures that failure of operations within the transaction does not lead to inconsistencies in the database.

From a user perspective, a transaction is any coherent sequence of operations that satisfies a goal, such as ‘find the times of flights from London to Paris’. If the user transaction does not require the database to be changed then it may not be necessary to package this as a technical database transaction.

An example of a transaction is a customer request to withdraw money from a bank account using an ATM. This involves getting details of the customer’s account, checking the balance, modifying the balance by the amount withdrawn, and sending commands to the ATM to deliver the cash. Until all of these steps have been completed, the transaction is incomplete and the customer accounts database is not changed.


Picture 1. The Structure of Transaction Processing Applications

Transaction processing systems are usually interactive systems in which users make asynchronous requests for service. Picture 1. illustrates the conceptual architectural structure of TP applications. First a user makes a request to the system through an I/O processing component. The request is processed by some application specific logic. A transaction is created and passed to a transaction manager, which is usually embedded in the database management system. After the transaction manager has ensured that the transaction is properly completed, it signals to the application that processing has finished.


Picture 2. The Software Architecture of an ATM System

Transaction processing systems may be organized as a ‘pipe and filter’ architecture with system components responsible for input, processing, and output. For example, consider a banking system that allows customers to query their accounts and withdraw cash from an ATM. The system is composed of two cooperating software components—the ATM software and the account processing 
software in the bank’s database server. The input and output components are implemented as software in the ATM and the processing component is part of the bank’s database server. Picture 2. shows the architecture of this system, illustrating the functions of the input, process, and output components.

Source : Sommerville, Ian. 2011. Software Engineering. 9th Ed. Boston: Pearson Education, Inc.

Associated Course: KI142303BKI142303B
[ Modified: Friday, 23 December 2016, 11:32 AM ]