Transaction processing

From Wikipedia, the free encyclopedia

Jump to: navigation, search In computer science, a transaction is a group of logical operations that must all succeed or fail as a group. Systems dedicated to supporting such operations are known as transaction processing systems. As an example, consider a typical banking operation, moving $500 from your savings account to your checking account. This seems like a single operation to the user but in fact consists of two: debiting the savings account by $500 and crediting the checking account by $500. If the debit operation succeeded and the credit did not, the $500 would disappear. This might still sound simplistic and easy to avoid, but consider that each of these two main operations may consist of several sub-operations, each of which may or may not fail; therefore we'll use these two "main" operations (debiting and crediting) as a generic alias for any number of elementary operations in a generic transaction. Transaction processing systems allow these two operations to be "grouped" into a single transaction so these sorts of consistency problems cannot occur. They do this by making copies of the data in question and then running the operations on the copied data. When both commands have successfully completed, the changed data are written back to the system in a single operation. If either operation failed, the copied data are simply discarded, and an error is reported. This desirable property is called atomicity and is one of the desirable ACID transaction properties. Standard transaction processing middleware, notably IBM's Information Management System, emerged in the 1960s and was often closely coupled to particular database management systems. Client-server computing embraced similar principles in the 1980s with mixed success. But, in more recent years, the distributed client-server model has become considerably more difficult to maintain. As the number of transactions grew in response to various online services (especially the Web), a single distributed database was not a practical solution. In addition, most online systems consist of a whole suite of programs operating together, as opposed to a strict client-server model where the single server could handle the transaction processing. Today a number of transaction processing systems are available that work at the inter-program level and which scale to large systems, including mainframes.

Database transaction

From Wikipedia, the free encyclopedia

Jump to: navigation, search A database transaction is a unit of interaction with a database management system or similar system that is treated in a coherent and reliable way independent of other transactions that must be either entirely completed or aborted. Ideally, a database system will guarantee all of the ACID properties for each transaction. In practice, these properties are often relaxed somewhat to provide better performance.

Contents
[hide]

1 Purpose of transaction 2 Transactional databases 3 Transactional filesystems 4 See also

5 External links [edit]

Purpose of transaction
In database products the ability to handle transactions allows the user to ensure that integrity of a database is maintained. A single transaction might require several queries, each reading and/or writing information in the database. When this happens it is usually important to be sure that the database is not left with only some of the queries carried out. For example, when doing a money transfer, if the money was debited from one account, it is important that it also be credited to the depositing account. Also, transactions should not interfere with each other. For more information about desirable transaction properties, see ACID. A simple transaction is usually issued to the database system in a language like SQL in this form: 1. Begin the transaction 2. Execute several queries (although any updates to the database aren't actually visible to the outside world yet) 3. Commit the transaction (updates become visible if the transaction is successful) If one of the queries fails the database system may rollback either the entire transaction or just the failed query. This behaviour is dependent on the DBMS in use and how it is set up. The transaction can also be rolled back manually at any time before the commit. Transactions are also called LUWs (Logical Units of Work) in some systems.

[edit]

Transactional databases
Databases that support transactions are called transactional databases. Most modern databases (such as IBM DB2, Firebird, Mimer SQL, PostgreSQL, MySQL, Microsoft SQL Server and Oracle) fall into this category. [edit]

Transactional filesystems
The newest version of the Microsoft NTFS filesystem supports transactions [1].

Relational DBMS
Edgar Codd worked at IBM in San Jose, California, in one of their offshoot offices that was primarily involved in the development of hard disk systems. He was unhappy with the navigational model of the Codasyl approach, notably the lack of a "search" facility which was becoming increasingly useful when the database was stored on disk instead of tape. In 1970 he wrote a number of papers that outlined a new approach to database construction that eventually culminated in the groundbreaking A Relational Model of Data for Large Shared Data Banks. In this paper he described a new system for storing and working with large databases. Instead of records being stored in some sort of linked list of free-form records as in Codasyl, Codd's idea was to use a "table" of fixed-length records. A linked-list system would be very inefficient when storing "sparse" databases where some of the data for any one record could be left empty. The relational model solved this by splitting the data into a series of normalized tables, with optional elements being moved out of the main table to where they would take up room only if needed.

In the relational model, related records are linked together with a "key". For instance, a common use of a database system is to track information about users, their name, login information, various addresses and phone numbers. In the navigational approach all of these data would be placed in a single record, and unused items would simply not be placed in the database. In the relational approach, the data would be normalized into a user table, an address table and a phone number table (for instance). Records would be created in these optional tables only if the address or phone numbers were actually provided. Linking the information back together is the key to this system. In the relational model some bit of information was used as a "key", uniquely defining a particular record. When information was being collected about a user, information stored in the optional (or related) tables would be found by searching for this key. For instance, if the login name of a user is unique, addresses and phone numbers for that user would be recorded with the login name as its key. This "re-linking" of related data back into a single collection is something that traditional computer languages are not designed for. Just as the navigational approach would require programs to loop in order to collect records, the relational approach would require loops to collect information about any one record. Codd's solution to the necessary looping was a set-oriented language, a suggestion that would later spawn the ubiquitous SQL. Using a branch of mathematics known as tuple calculus, he demonstrated that such a system could support all the operations of normal databases (inserting, updating etc.) as well as providing a simple system for finding and returning sets of data in a single operation. Codd's paper was picked up by two people at Berkeley, Eugene Wong and Michael Stonebraker. They started a project known as INGRES using funding that had already been allocated for a geographical database project, using student programmers to produce code. Beginning in 1973, INGRES delivered its first test products which were generally ready for widespread use in 1979. During this time a number of people had moved "through" the group perhaps as many as 30 people worked on the project, about five at a time. INGRES was similar to System R in a number of ways, including the use of a "language" for data access, known as QUEL QUEL was in fact relational, having been based on Codd's own Alpha language, but has since been corrupted to follow SQL, thus violating much the same concepts of the relational model as SQL itself. IBM itself did only one test implementation of the relational model, PRTV, and a production one, Business System 12, both now discontinued. Honeywell did MRDS for Multics, and now there are two new implementations: Alphora Dataphor and Rel. All other DBMS implementations usually called relational are actually SQL DBMSs.