Concurrency and reliability have long been “hot topics” of discussion among developers and users of distributed systems. The fundamental problem can be seen in a simple example, as follows.
Suppose two users are working on the same part of a database at the same time. They both UPDATE the same row in the same table, but they provide different values in the UPDATE. The UPDATE commands are sent to the database precisely at the same time. What does the database system do about this, and what are the rules governing its decision?
When discussing concurrency and reliability, developers often talk about the components of ACID: atomicity, consistency, isolation, and durability. Together, these properties guarantee that a database transaction is processed in a reliable, predictable manner. A transaction, in this case, can be defined as any set of operations that changes the state of the database. It could be something as simple as reading a value, deciding how to manipulate that value based on what was read, and then updating the value.
The atomicity property guarantees that a transaction is either completed in full or not completed at all. Thus, the result of an operation is always success or failure, and no transaction can result in a partial completion. Essentially, by making a transaction “atomic”, all the operations involved in the transaction are virtually combined into one single operation.
Two important rules provide transaction atomicity. First, as operations in a transaction occur, those operations must remain unknown to all other processes accessing the database at the same time. Other processes may see only the final product after the transaction is complete, or they will see no changes at all.
The second rule is somewhat of an extension of the first rule. It says that, if any operations involved in a transaction fail, the entire transaction fails, and the database is restored to the state before the transaction began. This prevents a transaction from being partially completed.
Next Page: Database Consistency