Transaction processing: Difference between revisions
Jump to navigation
Jump to search
imported>Howard C. Berkowitz (work in progress) |
imported>Howard C. Berkowitz (refs) |
||
| Line 4: | Line 4: | ||
| title = Transaction Internet Protocol Version 3.0 | | title = Transaction Internet Protocol Version 3.0 | ||
| author = Lyon J, Evans K, Klein J | | author = Lyon J, Evans K, Klein J | ||
| id = RFC2371 | |||
| date = July 1998 | | date = July 1998 | ||
| url = http://www.rfc-editor.org/rfc/rfc2371.txt}}</ref> A practical way to see if an application follows transaction processing is that an Internet sales application complying with it would never, ever, order something twice if the user got impatient and hit "order" more than once. | | url = http://www.rfc-editor.org/rfc/rfc2371.txt}}</ref></blockquote> | ||
A practical way to see if an application follows transaction processing is that an Internet sales application complying with it would never, ever, order something twice if the user got impatient and hit "order" more than once. | |||
Atomicity, which is achieved with resource locking and with various [[commit protocol]]s that can roll back to the starting state, is not the only characteristic of transaction processing. Atomicity is the first letter of the ISO ISO/IEC 10026-1:1992 Section 4 mnemonic usually used to characterize transaction processing: '''ACID''': | Atomicity, which is achieved with resource locking and with various [[commit protocol]]s that can roll back to the starting state, is not the only characteristic of transaction processing. Atomicity is the first letter of the ISO ISO/IEC 10026-1:1992 Section 4 mnemonic usually used to characterize transaction processing: '''ACID''': | ||
| Line 12: | Line 15: | ||
* '''I'''solation means that no operation outside the transaction can ever see the data in an intermediate state; a money trader can see the transferred funds on one account or the other, but never on both -- even if he ran his query while the transfer was still being processed. More formally, isolation means the transaction history is serializable. | * '''I'''solation means that no operation outside the transaction can ever see the data in an intermediate state; a money trader can see the transferred funds on one account or the other, but never on both -- even if he ran his query while the transfer was still being processed. More formally, isolation means the transaction history is serializable. | ||
*'''D'''urability refers to the guarantee that once the user has been notified of success, the transaction will persist, and not be undone. Transactions must be strictly fault tolerant; many stock and money trading applications not only keep logs and multiple coies of disks, but may run the transaction in parallem on a hot standby computer. A transaction is complete only when it is in a trusted and permanent log. | *'''D'''urability refers to the guarantee that once the user has been notified of success, the transaction will persist, and not be undone. Transactions must be strictly fault tolerant; many stock and money trading applications not only keep logs and multiple coies of disks, but may run the transaction in parallem on a hot standby computer. A transaction is complete only when it is in a trusted and permanent log. | ||
==References== | |||
{{reflist}} | |||
Revision as of 01:25, 22 July 2008
Transaction processing, minimally, is a way of carrying out client server interchanges such that they have the property of atomicity:
"Transaction" is the term given to the programming model whereby computational work performed has atomic semantics. That is, either all work completes successfully and changes are made permanent (the transaction commits), or if any work is unsuccessful, changes are undone (the transaction aborts). The work comprising a transaction(unit of work), is defined by the application.[1]
A practical way to see if an application follows transaction processing is that an Internet sales application complying with it would never, ever, order something twice if the user got impatient and hit "order" more than once.
Atomicity, which is achieved with resource locking and with various commit protocols that can roll back to the starting state, is not the only characteristic of transaction processing. Atomicity is the first letter of the ISO ISO/IEC 10026-1:1992 Section 4 mnemonic usually used to characterize transaction processing: ACID:
- Atomicity
- Consistency: whatever processing done leaves all affected databases in a legal state when the transaction starts and ends. Consistency sometimes overlaps security policy, as, for example, that all of a given customer's accounts must have a positive balance before any of a list of transactions can even start.
- Isolation means that no operation outside the transaction can ever see the data in an intermediate state; a money trader can see the transferred funds on one account or the other, but never on both -- even if he ran his query while the transfer was still being processed. More formally, isolation means the transaction history is serializable.
- Durability refers to the guarantee that once the user has been notified of success, the transaction will persist, and not be undone. Transactions must be strictly fault tolerant; many stock and money trading applications not only keep logs and multiple coies of disks, but may run the transaction in parallem on a hot standby computer. A transaction is complete only when it is in a trusted and permanent log.
References
- ↑ Lyon J, Evans K, Klein J (July 1998), Transaction Internet Protocol Version 3.0, RFC2371