Transaction Processing System Sim

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 11

Transaction processing system

From Wikipedia, the free encyclopedia


(Redirected from Transaction processing systems)

It has been suggested that this article or section be merged into Transaction processing. (Discuss) Proposed since November 2012.

Transaction processing is a style of computing that divides work into individual, indivisible operations, called transactions.[1] Atransaction processing system (TPS) or transaction server is a software system, or software/hardware combination, that supports transaction processing.
Contents
[hide]

1 History 2 List of transaction processing systems 3 Processing types

o o o o

3.1 Batch processing 3.2 Real-time processing 3.3 Time-sharing 3.4 Transaction processing 4 Transaction processing system features

o o o o o

4.1 Performance 4.2 Continuous availability 4.3 Data integrity 4.4 Ease of use 4.5 Modular growth 5 Databases and files

o o

5.1 Data warehouse 5.2 Backup procedures


father-son

5.2.1 Recovery process 5.2.2 Types of back-up procedures 5.2.2.1 Grandfather-


6 See also 7 References

5.2.2.2 Partial backups 5.2.3 Updating in a batch 5.2.4 Updating in real-time

8 Further reading

[edit]History

One of the first transaction processing systems was American Airline SABRE system, which became operational in 1960. Designed to process up to 83,000 transactions a day, the system ran on two IBM 7090 computers. SABRE was migrated to IBM System/360computers in 1972, and became an IBM product first as Airline control Program (ACP) and later as Transaction Processing Facility (TPF). In addition to airlines TPF is used by large banks, credit card companies, and hotel chains. The Hewlett-Packard NonStop system (formerly Tandem NonStop) was a hardware and software system designed for Online Transaction Processing (OLTP) introduced in 1976. The systems were designed for transaction processing and provided an extreme level of availability and data integrity.
[edit]List

of transaction processing systems

IBM Transaction Processing Facility (TPF) - 1960. Unlike most other transaction processing systems TPF is a dedicated operating system for transaction processing on IBM System z mainframes. Originally Airline Control Program (ACP).

IBM Information Management System (IMS) - 1966. A joint hierarchical database and information management system with extensive transaction processing capabilities. Runs on OS/360 and successors.

IBM Customer Information Control System (CICS) - 1969. A transaction manager designed for rapid, high-volume online processing, CICS originally used standard system datasets, but now has a connection

to IBM's DB/2 relational database system. Runs onOS/360 and successors and DOS/360 and successors, IBM AIX, VM, and OS/2. Non-mainframe versions are called TXSeries.

Tuxedo - 1980s. Transactions for Unix, Extended for Distributed Operations developed by AT&T Corporation, now owned by Oracle Corporation. Tuxedo is a cross-platform TPS.

UNIVAC Transaction Interface Package (TIP) - 1970s. A transaction processing monitor for UNIVAC 1100/2200 series computers.[2]

Burroughs Corporation supported transaction processing capabilities in its MCP operating systems. As of 2012 UNISYS ClearPath Enterprise Servers include Transaction Server, "an extremely flexible, highperformance message and application control system."[3]

Digital Equipment Corporation (DEC) Application Control and Management System (ACMS) - 1985. "Provides an environment for creating and controlling online transaction processing (OLTP) applications on the VMS operating system."[4][5] Runs on VAX/VMSsystems.

Digital Equipment Corporation (DEC) Message Control System (MCS-10) for PDP-10 TOPS10 systems.

Honeywell Multics Transaction Processing. Feature (TP) - 1979.[6] Transaction Management eXecutive (TMX) was NCR Corporation's proprietary transaction processing system running on NCR Tower 5000-series systems. This system was used mainly by financial institutions in the 1980s and 1990s.

Hewlett-Packard NonStop system - 1976. NonStop is an integrated hardware and software system specifically designed for transaction processing. Originally from Tandem Computers.

Transarc Encina - 1991.[7] Transarc was purchased by IBM in 1994. Encina was discontinued as a product and folded into IBM's TXSeries.[8] Encina support was discontinued in 2006.

[edit]Processing

types

Transaction processing is distinct from other computer processing models batch processing, time-sharing, and real-time processing.[9]
[edit]Batch

processing

Main article: Batch processing

Batch processing is execution of a series of programs (jobs) on a computer without manual intervention. Several transactions, called abatch are collected and processed at the same time. The results of each transaction are not immediately available when the transaction is being entered; [1] there is a time delay.
[edit]Real-time

processing

Main article: Real-time computing "Real time systems attempt to guarantee an appropriate response to a stimulus or request quickly enough to affect the conditions that caused the stimulus." [9] Each transaction in real-time processing is unique; it is not part of a group of transactions.
[edit]Time-sharing

Main article: Time-sharing Time sharing is the sharing of a computer system among multiple users, usually giving each user the illusion that they have exclusive control of the system. The users may be working on the same project or different projects, but there are usually few restrictions on the type of work each user is doing.
[edit]Transaction

processing

Main article: Transaction processing Transaction processing systems also attempt to provide predictable response times to requests, although this is not as critical as for real-time systems. Rather than allowing the user to run arbitrary programs as timesharing, transaction processing allows only predefined, structured transactions. Each transaction is usually short duration and the processing activity for each transaction is programmed in advance.
[edit]Transaction

processing system features

The following features are considered important in evaluating transaction processing systems. [9]
[edit]Performance

Fast performance with a rapid response time is critical. Transaction processing systems are usually measured by the number of transactions they can process in a given period of time.
[edit]Continuous

availability

The system must be available during the time period when the users are entering transactions. Many organizations rely heavily on their TPS; a breakdown will disrupt operations or even stop the business.
[edit]Data

integrity

The system must be able to handle hardware or software problems without corrupting data. Multiple users must be protected from attempting to change the same piece of data at the same time, for example two operators cannot sell the same seat on an airplane.
[edit]Ease

of use

Often users of transaction processing systems are casual users. The system should be simple for them to understand, protect them from data-entry errors as much as possible, and allow them to easily correct their errors.
[edit]Modular

growth

The system should be capable of growth at incremental costs, rather than requiring a complete replacement. It should be possible to add, replace, or update hardware and software components without shutting down the system.
[edit]Databases

and files

The storage and retrieval of data must be accurate as it is used many times throughout the day. A database is a collection of data neatly organized, which stores the accounting and operational records in the database. Databases are always protective of their delicate data, so they usually have a restricted view of certain data. Databases are designed using hierarchical, network or relational structures; each structure is effective in its own sense.

Hierarchical structure: organizes data in a series of levels, hence why it is called hierarchical. Its top to bottom like structure consists of nodes and branches; each child node has branches and is only linked to one higher level parent node.

Network structure: Similar to hierarchical, network structures also organizes data using nodes and branches. But, unlike hierarchical, each child node can be linked to multiple, higher parent nodes.

Relational structure: Unlike network and hierarchical, a relational database organizes its data in a series of related tables. This gives flexibility as relationships between the tables are built.

A relational structure.

A hierarchical structure. A network structure.

The following features are included in real time transaction processing systems:

Good data placement: The database should be designed to access patterns of data from many simultaneous users. Short transactions: Short transactions enables quick processing. This avoids concurrency and paces the systems.

Real-time backup: Backup should be scheduled between low times of activity to prevent lag of the server.

High normalization: This lowers redundant information to increase the speed and improve concurrency, this also improves backups.

Archiving of historical data: Uncommonly used data are moved into other databases or backed up tables. This keeps tables small and also improves backup times.

Good hardware configuration: Hardware must be able to handle many users and provide quick response times.

[edit]Data

warehouse

Main article: Data warehouse

A data warehouse is a database that collects information from different sources. When it's gathered in real-time transactions it can be used for analysis efficiently if it's stored in a data warehouse. It provides data that are consolidated, subject-oriented, historical andread-only:

Consolidated: Data are organised with consistent naming conventions, measurements, attributes and semantics. It allows data from a data warehouse from across the organization to be effectively used in a consistent manner.

Subject-oriented: Large amounts of data are stored across an organization, some data could be irrelevant for reports and makesquerying the data difficult. It organizes only key business information from operational sources so that it's available for analysis.

Historical: Real-time TPS represent the current value at any time, an example could be stock levels. If past data are kept, querying the database could return a different response. It stores series of snapshots for an organisation's operational data generated over a period of time.

Read-only: Once data are moved into a data warehouse, it becomes read-only, unless it was incorrect. Since it represents a snapshot of a certain time, it must never be updated. Only operations which occur in a data warehouse are loading and querying data.

[edit]Backup

procedures

A Dataflow Diagram of backup and recovery procedures.

Since business organizations have become very dependent on TPSs, a breakdown in their TPS may stop the business' regular routines and thus stopping its operation for a certain amount of time. In order to prevent data loss and minimize disruptions when a TPS breaks down a well-designed backup and recovery procedure is put into use. The recovery process can rebuild the system when it goes down.
[edit]Recovery process

A TPS may fail for many reasons. These reasons could include a system failure, human errors, hardware failure, incorrect or invalid data, computer viruses, software application errors or natural or man-made disasters. As it's not possible to prevent all TPS failures, a TPS must be able to cope with failures. The TPS

must be able to detect and correct errors when they occur. A TPS will go through a recovery of the database to cope when the system fails, it involves the backup, journal, checkpoint, and recovery manager:

Journal: A journal maintains an audit trail of transactions and database changes. Transaction logs and Database change logs are used, a transaction log records all the essential data for each transactions, including data values, time of transaction and terminal number. A database change log contains before and after copies of records that have been modified by transactions.

Checkpoint: The purpose of checkpointing is to provide a snapshot of the data within the database. A checkpoint, in general, is any identifier or other reference that identifies the state of the database at a point in time. Modifications to database pages are performed in memory and are not necessarily written to disk after every update. Therefore, periodically, the database system must perform a checkpoint to write these updates which are held in-memory to the storage disk. Writing these updates to storage disk creates a point in time in which the database system can apply changes contained in a transaction log during recovery after an unexpected shut down or crash of the database system.

If a checkpoint is interrupted and a recovery is required, then the database system must start recovery from a previous successful checkpoint. Checkpointing can be either transaction-consistent or non-transactionconsistent (called also fuzzy checkpointing).Transaction-consistent checkpointing produces a persistent database image that is sufficient to recover the database to the state that was externally perceived at the moment of starting the checkpointing. A non-transaction-consistent checkpointing results in a persistent database image that is insufficient to perform a recovery of the database state. To perform the database recovery, additional information is needed, typically contained in transaction logs. Transaction consistent checkpointing refers to a consistent database, which doesn't necessarily include all the latest committed transactions, but all modifications made by transactions, that were committed at the time checkpoint creation was started, are fully present. A non-consistent transaction refers to a checkpoint which is not necessarily a consistent database, and can't be recovered to one without all log records generated for open transactions included in the checkpoint. Depending on the type of database management system implemented a checkpoint may incorporate indexes or storage pages (user data), indexes and storage pages . If no indexes are incorporated into the checkpoint, indexes must be created when the database is restored from the checkpoint image.

Recovery Manager: A recovery manager is a program which restores the database to a correct condition which can restart the transaction processing.

Depending on how the system failed, there can be two different recovery procedures used. Generally, the procedures involves restoring data that has been collected from a backup device and then running the transaction processing again. Two types of recovery are backward recovery and forward recovery:

Backward recovery: used to undo unwanted changes to the database. It reverses the changes made by transactions which have been aborted. It involves the logic of reprocessing each transaction, which is very time-consuming.

Forward recovery: it starts with a backup copy of the database. The transaction will then reprocess according to the transaction journal that occurred between the time the backup was made and the present time. It's much faster and more accurate.

See also: Checkpoint restart


[edit]Types of back-up procedures

There are two main types of Back-up Procedures: Grandfather-father-son and Partial backups:
[edit]Grandfather-father-son

This procedure refers to at least three generations of backup master files. thus, the most recent backup is the son, the oldest backup is the grandfather. It's commonly used for a batch transaction processing system with a magnetic tape. If the system fails during a batch run, the master file is recreated by using the son backup and then restarting the batch. However if the son backup fails, is corrupted or destroyed, then the previous generation of backup (the father) is used. Likewise, if that fails, then the generation of backup previous to the father (i.e. the grandfather) is required. Of course the older the generation, the more the data may be out of date. Organizations can have many generations of backup.
[edit]Partial backups

This only occurs when parts of the master file are backed up. The master file is usually backed up to magnetic tape at regular times, this could be daily, weekly or monthly. Completed transactions since the last backup are stored separately and are called journals, orjournal files. The master file can be recreated from the journal files on the backup tape if the system is to fail.
[edit]Updating in a batch

This is used when transactions are recorded on paper (such as bills and invoices) or when it's being stored on a magnetic tape. Transactions will be collected and updated as a batch when it's convenient or economical to process them. Historically, this was the most common method as the information technology did not exist to allow real-time processing.

The two stages in batch processing are:

Collecting and storage of the transaction data into a transaction file - this involves sorting the data into sequential order. Processing the data by updating the master file - which can be difficult, this may involve data additions, updates and deletions which may require being performed in a certain order. If an error occurs, then the entire batch fails.

Updating in batch requires sequential access - since it uses a magnetic tape this is the only way to access data. A batch will start at the beginning of the tape, then reading it from the order it was stored; it's very timeconsuming to locate specific transactions. The information technology used includes a secondary storage medium which can store large quantities of data inexpensively (thus the common choice of a magnetic tape). The software used to collect data does not have to be online - it doesn't even need a user interface.
[edit]Updating in real-time

This is the immediate processing of data. It provides instant confirmation of a transaction. It may involve a large number of users who are simultaneously performing transactions which change data. Because of advances in technology (such as the increase in the speed of data transmission and larger bandwidth), real-time updating is possible. Steps in a real-time update involve the sending of a transaction data to an online database in a master file. The person providing information is usually able to help with error correction and receives confirmation of the transaction completion. Updating in real-time uses direct access of data. This occurs when data are accessed without accessing previous data items. The storage device stores data in a particular location based on a mathematical procedure. This will then be calculated to find an approximate location of the data. If data are not found at this location, it will search through successive locations until it's found. The information technology used could be a secondary storage medium that can store large amounts of data and provide quick access (thus the common choice of a magnetic disk).
[edit]See

also

Transaction processing Server (computing) Online transaction processing

Customer Integrated System

[edit]References

1. 12,2012. 2. 14, 2012. 3. 4. 5. 6. 7. 8. 9.

^ IBM Corporation. "CICS Transaction Server for z/OS, Version 3.2 Transaction processing". Retrieved Nov

^ "Terminals Help Manage Aluminum Firm's Production". Computerworld. July 26, 1976. Retrieved November

^ UNISYS Corporation (2012). Transaction Server for ClearPath MCP Configuration Guide. ^ Digital Equipment Corporation (1989). VAX ACMS Guide to Creating Transaction Processing Applications. ^ Bell, Gordon. "Digital Computing Timeline (1985)". Retrieved November 15, 2012. ^ Van Vleck, Thomas. "Multics Glossary -T-". Retrieved November 15, 2012. ^ Transarc. "Corporate Overview". Retrieved November 16, 2012. ^ IBM Corporation. "TXSeries for Multiplatforms". Retrieved November 16, 2012. ^ a b c Schuster, Stewart A. (June 15, 1981). "In Depth: Relational Data Base Management". Computerworld. Retrieved November 16, 2012.

[edit]Further

reading

Gerhard Weikum, Gottfried Vossen, Transactional information systems: theory, algorithms, and the practice of concurrency control and recovery , Morgan Kaufmann, 2002, ISBN 1-55860-508-8

You might also like