Transaction Processing Fundamentals

A transaction is a set of related tasks that 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.

Transactions bind multiple tasks together. For example, imagine that an ASP.NET page 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.

As this example shows, a transaction can be confined to a single data resource, such as a database or message queue. It is common for these data resources to provide local transaction capabilities. 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 latitude to incorporate several distinct operations occurring on different systems into a single pass or fail action.

See Also

Processing Transactions | ACID Properties | Transaction Boundaries | Distributed Transactions