Local Transaction

There are two techniques for implementing local transactions. In both cases, locks must be acquired on all data to be updated.

On write-ahead logging (WAL), durability is guaranteed by copying the original (unchanged) data plus "redo" and "undo" information to a log before changing the database. That allows the database to return to a consistent state in the event of a crash. Imagine a program that is in the middle of performing some operation when the machine it is running on loses power. Upon restart, that program might need to know whether the operation it was performing succeeded, succeeded partially, or failed. If a write-ahead log is used, the program can check this log and compare what it was supposed to be doing when it unexpectedly lost power to what was actually done. On the basis of this comparison, the program could decide to undo what it had started, complete what it had started, or keep things as they are.

WAL allows updates of a database to be done in-place. Another way to implement atomic updates is with shadow paging, which is not in-place. The main advantage of doing updates in-place is that it reduces the need to modify indexes and block lists.

Modern file systems typically use a variant of WAL called journaling. Journaling keeps track of changes not yet committed in a file and a background task will check the journal and apply the changes and will clear the journal. Journaling makes writes faster since they just get added to a log file and updating the actual database or filesystem could happen in the background.

In shadowing, updates are applied to a partial copy of the database, and the new copy is activated when the transaction commits.

Distributed Transaction

For distributed transactions two-phase commit protocol provides atomicity. A coordinator is required in a distributed transaction. In phase 1, the coordinator sends the write request to all the servers and they store this command in a log table and respond to the coordinator if the action was successful or not. If all the participants respond OK, the coordinator sends a signal to each server to commit the changes. If all the participants respond OK in this phase then the transaction has been finished successfully otherwise, the coordinator sends instructions to all servers to roll back the transaction.