Understand transaction processing, the ACID properties, record locking and the deadlock that can result, redundancy and database recovery.

Atomicity means the transaction is all or nothing. The transfer has two parts, the debit and the credit; atomicity guarantees that either both happen or neither does. If the system failed after the debit but before the credit, the whole transaction would be rolled back so the money is not lost, leaving the accounts as they were before.

Consistency means the transaction takes the database from one valid state to another. Before and after the transfer the total money across the two accounts is unchanged and all rules (such as no impossible balances) still hold; the transaction never leaves the database in an invalid state where the money has been debited but not credited.

Markers reward explaining atomicity as both-or-neither with the rollback consequence, and consistency as moving between valid states with the invariant (total money preserved) maintained.

The lost update problem occurs when two transactions read the same record and both write back changes, so one update overwrites and loses the other. Record locking prevents this by locking a record while one transaction is updating it, so a second transaction cannot change the same record until the lock is released, ensuring updates are applied one at a time.

Locking can cause deadlock when transaction A locks record 1 and then needs record 2, while transaction B has locked record 2 and needs record 1: each waits for a record the other holds, so neither can proceed. A database system deals with deadlock by detecting it (for example finding a cycle of waiting transactions) and aborting and rolling back one transaction so the other can continue, or by preventing it by requiring locks to be acquired in a fixed order.

Markers reward how locking serialises updates to prevent lost updates, the mutual-wait description of deadlock, and a valid resolution (abort and retry one, or order the locks).