Definition of transaction processing

Transaction processing

In many large, critical applications, computers perform a number of tasks every second. More often than not, the tasks themselves are combined to accomplish a business requirement, called a transaction. What happens if you can successfully perform a task and an error occurs in the second or third related task? This error is likely to cause the system to be in an inconsistent state. The transaction becomes so important that it can get the system out of this inconsistent state.
Microsoft has initially used Microsoft Transaction Server (MTS) to process transactions. With the release of Windows 2000, Microsoft has further improved MTS to make it part of COM + or Component Services.
This chapter describes the transactional nature of Component Services. Learn how they are used to support the transactions of applications developed on the I i s.
The main contents of this chapter include:
? The definition of transaction processing.
? The purpose of transaction processing.
? How transaction processing works in COM +.
? Transactional a S p page.
First, let's take a look at what is transaction processing.
19.1 Definition of transaction processing
This book has covered a number of concepts related to transaction processing, but what exactly is the transaction processing. In the mainframe era, there was a transaction process. Products such as user Information control systems (CICS), Tuxedo, and topend are examples of transaction processing systems that provide transactional services to applications.
In order to discuss transaction processing, you must first define the transaction.
A transaction is a minimal unit of work that works as a whole, whether successful or not.
There will be no partially completed transactions. Because a transaction is made up of several tasks, if a transaction succeeds as a whole, then each task in the transaction must succeed. If a portion of the transaction fails, the repair transaction fails.
When a transaction fails, the system returns to the state before the transaction started. This process of canceling all changes is called "rollback" (rollback). For example, if a transaction successfully updates two tables and fails to update the third table, the system restores the two updates to their original state and returns them to their previous status.
19.1.1 Keep the application intact
The key to any application is to ensure that all of the actions it performs are correct, and that if the application only partially completes the operation, the data in the application, or even the entire system, will be in an inconsistent state. For example, look at the example of bank transfers, if you raise money from an account and make an error before the money reaches another account, then apply
The data in the program is wrong, and it loses its integrity, which means the money will disappear somehow.
There are two ways to overcome this type of error:
? In the traditional programming model, the developer must prevent any way of operation failure. For any failure point, the developer must add a measure that supports the application's return to the state before the start of the operation. In other words, the developer must add code to enable the system to revert to the status quo (undo) If the operation is wrong.
? A simpler approach is to operate within the context of a transactional system, where the task of a transactional system is to ensure that the entire transaction is either completely successful or doing nothing. If all the tasks of a transaction are successfully completed, the changes in the application are presented to the system and the system processes the next transaction or task. If a part of the operation does not complete successfully, this causes the system to be in an invalid state, rolling back changes to the system, and returning the application to its original state.
The ability of a transaction processing system is to embed the knowledge that completes these operations into the system itself. Developers do not have to write code to restore the system to the original, all they need to do is tell the system if the task is successful and the rest is done automatically by the transaction system.
Another benefit of transaction processing systems when helping developers solve complex problems is their acid properties.
19.1.2 ACID Properties
When a transaction system creates a transaction, it ensures that the transaction has certain attributes. Component developers assume that the characteristics of the transaction should be those that do not require their personal management. These properties are called ACID properties.
Acid is: atomicity (atomicity), consistency (consistency), isolation (isolation), and persistence (durabilily).
1. Atomic Sex
The atomicity attribute is used to identify whether a transaction is completely completed, any updates to a transaction are completely completed on the system, and if for some reason the transaction does not complete its entire task, the system returns to the state before the transaction started.
Let's take another look at the example of bank transfers. If an error occurs during the transfer process, the entire transaction is rolled back. The transaction is written to disk and the changes are persisted only if all parts of the transaction are executed successfully.
In order to provide the ability to rollback or undo uncommitted changes, many data sources use a logging mechanism. For example, SQL Server uses a write-ahead transaction log, which is written on the transaction log before the data is applied (or submitted to) to the actual data page. However, some other data sources are not relational database management systems (RDBMS), and they manage uncommitted transactions in a completely different way. This technique should be available for managing transactions whenever a transaction rolls back and the data source can undo all uncommitted changes.
2. Consistency
Transactions enforce consistency in system integrity, which is achieved by ensuring that any transaction of the system is finally in a valid state. If the transaction completes successfully, all changes in the system are applied correctly and the system is in a valid state. If an error occurs in a transaction, all changes in the system are automatically rolled back and the system returns to its original state. Because affairs Open
The system is in a consistent state at the beginning, so the system is still in a consistent state.
Let's look back at the example of bank transfers, which are in a valid state before the account conversion and the transfer of funds. If the transaction completes successfully, and the transaction is committed, the account is in a new, valid state. If a transaction fails, the account returns to its original valid state after termination.
Remember that transactions are not responsible for enforcing data integrity, but only for ensuring that the data is returned to a consistent state after the transaction commits or terminates. The task of understanding data integrity rules and writing code to achieve integrity often falls on the developer's shoulders, and they are designed according to business requirements.
When many users use and modify the same data at the same time, transactions must maintain the integrity and consistency of their data. So we further study the next feature in a C I-D feature: Isolation.
3. Isolation
Perform transactions in the quarantine state so that they appear to be the only actions that the system performs within a given time. If there are two transactions running at the same time and performing the same function, the isolation of the transaction will ensure that each transaction is considered only in the system by the transaction.
This attribute is sometimes referred to as serialization, in order to prevent confusion between transaction operations, the request must be serialized or serializable so that only one request at a time is used for the same data.
Importantly, the state of the system may be inconsistent in the isolated state, ensuring that the system is in a consistent state before closing the transaction. However, in each individual transaction, the state of the system may change. If a transaction is not running in isolation, it may access data from the system, and the system may be in an inconsistent state. By providing things
Quarantine can prevent the occurrence of such incidents.
In the case of the bank, this means that in this system, other processes and transactions do not see any changes in our transactions until our transaction is complete, which is important for the termination. If there is another process that is handled according to the account balance, and it can see the changes it has made before our transaction completes, then the decision of the process may
Based on the wrong data, because our transaction may terminate. This explains why the transaction has changed until the transaction is complete before it is visible to other parts of the system.
Isolation not only guarantees that multiple transactions cannot modify the same data at the same time, but also guarantees that the changes in the transaction will not be visible to another transaction until the change is committed or terminated, and that the concurrent transactions have no effect on each other. This means that all data required to be modified or read has been locked in the transaction until the transaction completes to be released. Most databases, such as SQL Server and other RDBMS, are isolated by using locks, and each data item or dataset involved in a transaction uses locks to prevent concurrent access.
4. Durability
Persistence means that any changes that occur in the system will be permanent once the transaction is executed successfully. There should be some checkpoints to prevent loss of information when the system fails. Even if the hardware itself fails, the state of the system can still be rebuilt by recording the tasks completed in the log. The concept of persistence allows developers to assume that no matter what happens after the system, the
A business is a permanent part of the system.
In the case of the bank, the transfer of funds is permanent and remains in the system. This may sound simple, but it relies on writing data to disk, especially when the transaction is fully completed and committed before it is written to disk.
All of these transaction attributes, regardless of how they are related internally, simply guarantee that the data involved in the transaction is properly managed from the beginning of the transaction to the completion of the transaction, regardless of the success of the transaction.