It is responsible for making a smooth and predictable technique called transaction processing. Affairs ensures that data-oriented resources are not permanently updated unless all operations within the transactional unit are successful. By combining a set of related operations into one either either all successful units, you can simplify the error recovery and make the application more reliable.
The transaction processing system consists of computer software and computer software that carries a transaction, this application performs the routine transaction required by the business. Managing sales order inputs, ticket reservations, salary, employee records, production and delivery systems are such systems.
Basic principle of transaction processing
The transaction is a set of related tasks for success or failure as a unit. In transaction terms, the transaction is either submitted or aborted. To submit a transaction, all participants must ensure that any changes to the data are permanent. Regardless of the system crashes or other incoming events that cannot be expected, the changes must be lasting.
As long as there is a participant unable to make this guarantee, the entire transaction will fail. All data changes within the transaction range will roll back to a specific setup point.
The transaction is bound to multiple tasks. For example, assume that an ASP.NET page performs two tasks. It first creates a new table in the database. Then call the dedicated object to collect and format the data and insert data in the new table. These two tasks are related or interdependent, so the new table should be avoided unless the data is filled. Executing two tasks within a transaction will strengthen the relationship between the two. If the second task fails, the first task rolls back to the point before creating a new table.
As shown in this example, transactions can be restricted to a data resource, such as a database or message queue. These data resources typically provide local transaction functions. These transactions are controlled by data resource and manage it easily and efficiently.
The transaction can also span multiple data resources. Distributed transactions enable you to combine several different operations that appear on different systems into a single success or failure operation.
ACID attribute
The word ACID expresses the role of the transaction in the mission-critical application. ACID is created by the transaction pioneer, represents inertability, consistency, isolation, and persistence.
These attributes ensure the security of presence, strengthening the role of transactions as a "full or no" proposition, and this proposition is designed to reduce management loads when there are many variables.
Unmetibility
A series of operations occurs between a work unit where the application's begin transaction and end transaction statements. The transaction is only executed once, and it is not enough, that is, complete all work or do not do anything.
The operation associated with a transaction usually has a common goal and is interdependent. If the system only performs one subset of these operations, the overall goal of the transaction may be destroyed. The non-variability eliminates the possibility of system processing operation subset.
consistency
The transaction is a complete unit because it maintains the consistency of the data, and the data is consistently converted from one data to another.
Consistency requires data that retains transaction binding in semantics. Some responsibilities of certain maintenance consistency are borne by the application developers, and they must ensure that the application has enforced all known integrity constraints. For example, when developing an application for transfer, avoid moving the decimal point during the transfer process.
Isolation
The transaction is an isolation unit that allows transactions that can be performed in parallel to perform a unique transaction running in the system.
Isolability requirements Even if there may be other transactions that are running, each transaction is like a unique transaction in the operational data store. The transaction should never look at the intermediate stage of other transactions.
The highest isolation level will be obtained when the transaction can be serialized. At this level, the results obtained from a set of parallel executable transactions are the same as those obtained by continuously run each transaction. Since height isolation limits the number of transactions that can be performed in parallel, some applications reduce the isolation level to exchange greater throughput.
Persistent
The transaction is also a recovery unit. If the transaction is successful, the system will still guarantee the transaction even if the computer crashes immediately after the submission is submitted. A dedicated record allows the system's restart to complete unfinished operations to sustain transactions.
Transaction border
Transaction boundaries define the range of transactions. Objects within the transaction border share a public transaction identifier.
Various transaction identification resources can participate in the transaction when executing. For example, if the application is connected to the database within the transaction range, the transaction flows to this resource and expands the transaction boundary to include the database server. A transaction that can be designed across processes and computers. Therefore, the transaction boundary is an abstract concept that manages consistency that manages cross-process boundary and computer boundaries. Control for transaction borders depends on transaction models selected for the application: manual or automatic. In manual transactions, the transaction boundary is controlled with explicit commands that start and end transactions. The second transaction that is known as nested transactions can be started from a transaction boundary. It is until all subordinate transactions are submitted, and their parent is committed.
Automatic transactions based on the declaration feature set management transaction boundaries for each component. The transaction automatically flows to the object that is instructing to participate in the transaction and skips the object indicated outside the transaction. Unable to nested the transaction when using an automated transaction model.
Distributed transaction
Distributed Transaction (TP) system aims to assist transactions across transactions in distributed environments. With the support of the distributed TP system, the application can combine different activities into a transactional unit, including the message from the Microsoft Message Queue (MSMQ) queue, store the message in the Microsoft SQL Server database, will all Some messages are removed from the Oracle server database, and so on. Because distributed transactions across multiple database resources, it is important to force the ACID attribute to maintain data consistency on all resources.
As described later, the distributed TP system consists of a number of cooperation entities. These entities are logically and can reside on or different computers on the same computer.
Transaction (TP) monitor
The TP monitor is software between transaction identification applications and resource collections. It optimizes the activity of the operating system so that the network communication is smooth and connects multiple clients to multiple applications that might access multiple data resources.
You are not writing an application (distributed environment) that manages multi-user, but writes applications composed of a single transaction request. The monitor scales the application as needed.
Distributed Transaction Coordinator (DTC) is a TP monitor for Microsoft Windows 2000.
Transaction manager
In distributed transactions, each participating resource has a local transaction manager (TM) to track transactions that are incorporated on this computer. The TP monitor assigns an additional task between all activities between the local TM to a TM. The TM of this coordinated transaction activity is called root TM or coordinated TM.
TM coordinates and manages all transaction processing functions, but does not have the ability to directly manage data. Resource Manager handles activities related to data.
Resource manager
The resource manager is a system service that manages persistence or persistent data in the database, continuous message queue or transactional file system. Resource Manager stores data and performs fault recovery.
SQL Server and MSMQ provide resource manager involved in distributed transactions. Oracle, Sybase, Informix, IBM (IBM DB2) and INGRES also provide compatible resource manager for their respective database products.
Resource distributor
The resource allocator manages the shared non-persistent state. For example, an ODBC resource distributor manages a database connection pool that is reclaimed when it is no longer needed.
Transaction model
To make the .NET framework object to participate in automated transactions, the .NET Framework class must register with Windows 2000 component service. But not all transactions are automatic. The activities performed when writing a transaction program depends on the selected transaction model. The public language running library supports manual and automatic transaction models.
Manual business
Microsoft ActiveX Data Objects (ADO), OLE DB, OTS Connection (ODBC), and Microsoft Message Queue (MSMQ) resource API support manual transaction.
Manual business allows explicitly starting transactions, controls each connection and resource registration within the transaction boundary to determine transaction results (submit or abort) and end transactions. Although this model provides standard control of the transaction, it lacks a simplified operation of the built-in automatic transaction model. For example, there is no automatic registration and coordination between the data stores in manual transactions. In addition, unlike automatic transactions, the transactions in manual transactions are not flowing between objects. If you choose to manually control a distributed transaction, you must manage recovery, concurrency, security, and integrity. That is, all programming methods needed to maintain the ACID attribute associated with transaction processing must be applied.
Manual business and ADO.NET
SQL clients and OLE DB .NET providers support manual transactions in the public language runtime. In ADO.NET, both .NET providers can be used to control transactions.
Both providers include a group of managed objects that create database connections, start transactions, and submit or rollback transactions. The main difference between the two is their connection mechanism. SQL client .NET provider provides a set of objects that directly call SQL Server. Instead, OLE DB .NET Provider enables data access using this OLE DB.
ADO.NET transactions are processed internally in the database and are not supported by Microsoft Distributed Transaction Coordinator (DTC) or any other transactional mechanism.
Manual business and MSMQ
Components written in hosted languages (such as Microsoft Visual Basic .NET) can send and receive messages from Microsoft Message Queuing (MSMQ).
MSMQ is a technology that implements a message queue in an application. Use MSMQ to create or delete message queues, send or receive messages, and manage messages. The transaction is an important part of the enterprise system, and the enterprise system often requires the MSMQ asynchronous function.
The public language runtime supports manual transactions through the MessageQueueTransaction class. The MSMQ transaction is completely processed in the internal processing of the MSMQ engine and is not supported by the Microsoft Distributed Transaction Coordinator (DTC) or any other transactional mechanism.
Automatic transaction
Microsoft Transaction Server (MTS), COM 1.0 and public language runtime supports the same automatic distributed transaction model.
ASP.NET Page, XML Web Services method or .Net Framework class once is labeled as participating transactions, they will be automatically executed within the transaction. The transactional behavior of the object can be controlled by setting a transaction feature value in the page, an XML Web Services method, or class. The characteristic value is in turn to determine the transactional behavior of the object of object. Therefore, depending on the value of the declaration characteristics, the object will automatically participate in existing transactions or ongoing transactions, becoming the root of new transactions or does not participate in transactions. The grammar of the statement of the transaction characteristics is slightly different in the .net framework class, the ASP.NET page, and the XML Web Services method.
Declarative transaction features Specify how objects participate in transactions and how to be configured in programming. Although this declaration level indicates the logic of the transaction, it is a step that has been removed from a physical transaction. Physical transaction occurs when a transactional object accesss a database or a data resource such as a message queue. Automatically flow to the appropriate resource manager with an object-associated transaction. An associated driver such as OLE DB, OTS Connection (ODBC), or ActiveX Data Object (ADO) is found in the context of the object and registers in this transaction through a Distributed Transaction Coordinator (DTC). The entire physical transaction is automatically occurred.
Automatic transaction and ASP.NET
ASP.NET supports automated transactions on systems running Microsoft Windows 2000. Insert transaction instructions in the ASP.NET page, you can indicate that the page is involved in existing transactions, starting new transactions or never participates in transactions.
The following table lists and describes the transaction instructions available in ASP.NET.
instruction
Description
Disabled
Indicates that ASP.NET will ignore the transaction context. This is the default transaction status.
NotSupported
Indicates that the page is not running within the transaction. After processing the request, the object context is created regardless of whether there is an activity transaction.
Supported
Indicates that the page is run in the context of existing transactions. If there is no transaction, the page is running without transaction.
Required
This page is run in the context of existing transactions. This page will start a transaction if there is no business.
Requiresnew
Indicates that the page requires transactions and launches new transactions for each request.
You can indicate the transaction support level on the page by placing instructions in your code. For example, insert the following instructions to ensure that page activity is always executed in the transaction range.
<% @ Page Transaction = "Required"%>
If you ignore this transaction, you will disable your transaction.
