Home > Articles

  • Print
  • + Share This
Like this article? We recommend

Like this article? We recommend

Atomicity, Consistency, Isolation, and Durability (ACID)

When you perform database operations that are interrelated, you need to ensure referential integrity almost every time. Suppose your code performs deposits and withdrawals from bank accounts, and a customer wants to transfer money from his savings account to his checking account. Your code would first withdraw the money from the savings account, and then deposit it into the checking account. It would be a two-step operation. But suppose that the second step fails for some reason. The customer would have a lower balance in his savings account since the money was withdrawn, but the same amount in his checking account because no money was deposited. What's needed is a way to ensure an "all or nothing" transaction.

Transactions need to provide atomicity, consistency, isolation, and durability—usually referred to as ACID properties. Table 1 sums up these four properties.

Table 1 ACID Properties




The "all or nothing" property of transactions. A transaction will either commit or abort. If a transaction commits, all of its effects remain; if it aborts, all of its effects are undone.


A transaction always transforms the state of the system from one consistent state to another. As a result, any single transaction (or any sequence of transactions) leaves the system in a consistent state.


If two transactions are executing concurrently, the changes made by one transaction are isolated from the other. Although two or more transactions may run in parallel, the system provides the illusion that the transactions run one at a time. This prevents one transaction from being affected by the uncommitted updates being made by another transaction.


Once a transaction commits, its effects persist even if there are system failures.

A Solution

Your first line of defense would have been to use an ADO.NET transaction. This would have enabled you to either commit or roll back the SQL operations. This is the recommended approach almost every time when you need to support transactions. But this takes some extra code, not to mention the fact that the problem may have been caused by the gnarly math rather than the database access. ADO.NET transactions would work, but there's a better way for web services.

A More Compelling Solution

Web services provide an automatic transaction mechanism. Any web method can automatically run within the scope of a transaction. All you need to do to take advantage of this capability is add a property to the WebMethod attribute—there's no extra code required. If an exception is thrown from within the web method and not caught, the transaction will be aborted automatically; if no exceptions are thrown, the transaction is committed. You can catch exceptions within the web method, but then you have to throw an exception—after you've performed any steps that you need to perform—in order to abort the transaction. This article shows you how to use automatic web service transactions effectively.

  • + Share This
  • 🔖 Save To Your Account