Transaction Fundamentals

Transactions bind multiple tasks together. For example, imagine that an application performs two tasks. First, it creates a new table in a database. Next, it calls a specialized object to collect, format, and insert data into the new table. These two tasks are related and even interdependent, such that you want to avoid creating a new table unless you can fill it with data. Executing both tasks within the scope of a single transaction enforces the connection between them. If the second task fails, the first task is rolled back to a point before the new table was created.

To ensure predictable behavior, all transactions must possess the basic ACID properties (atomic, consistent, isolated, and durable). These properties reinforce the role of mission-critical transactions as all-or-none propositions. For more information on ACID, please see ACID Properties. In summary, ACID guarantees that a set of related tasks either succeed or fail as a unit. In transaction processing terminology, the transaction either commits or aborts. For a transaction to commit, all participants must guarantee that any change to data will be permanent. Changes must persist despite system crashes or other unforeseen events. If even a single participant fails to make this guarantee, the entire transaction fails. All changes to data within the scope of the transaction are rolled back to a specific set point.

A transaction can be confined to a single data resource, such as a database or message queue. In this scenario, the local transaction is managed by the Transaction Manager provided by System.Transactions , which generates performance gain. Controlled by the data resource, these transactions are efficient and easy to manage.

Transactions can also span multiple data resources. Distributed transactions give you the ability to incorporate several distinct operations occurring on different systems into a single pass or fail action. In this scenario, the transactions are coordinated by the Microsoft Distributed Transaction Coordinator (MSDTC) that resides in each system.

When you develop a transactional application using the classes provided by System.Transactions, you do not need to worry about what kind of transactions you need, or the transaction manager involved. The System.Transactions infrastructure automatically manages these for you.

When you create a transaction, you can specify the isolation level that applies to the transaction. The isolation level, defined by the IsolationLevel class, determines what level of access other transactions will have to the data affected by your transaction.

You can create transactions using ADO.NET, System.EnterpriseServices, or the new transactional programming model provided by the System.Transactions namespace. The Features Provided by System.Transactions section discusses the features that you can use to write a transactional application using the System.Transactions namespace.

See Also

Concepts

Features Provided by System.Transactions

Send comments about this topic to Microsoft.

Copyright © 2007 by Microsoft Corporation. All rights reserved.