Transaction processing and the ACID properties (atomicity, consistency, isolation, durability), record locking and serialisation to manage concurrent access, and redundancy through commitment ordering and backups.

Levels-of-response question; reward the four ACID properties applied plus locking.

Atomicity: a transaction is all-or-nothing, so a transfer that debits one account and credits another either completes fully or is rolled back, never leaving money debited but not credited. Consistency: a transaction takes the database from one valid state to another, preserving rules such as non-negative balances. Isolation: concurrent transactions do not interfere; each behaves as if it ran alone, so a half-finished transfer is not seen by others. Durability: once committed, changes survive a crash or power loss (written to permanent storage).

Record locking supports isolation: while one transaction is updating a record it locks it so others must wait, preventing the lost-update problem where two simultaneous edits overwrite each other. The drawback is that careless locking can cause deadlock, so an ordering or timeout is used. Top marks need all four ACID properties applied to the banking context plus locking explained.

Lost update (2 marks): two transactions read the same record at the same time, each modifies its own copy and writes back; the second write overwrites the first, so one update is lost (for example two clerks both book the last seat, and one booking vanishes).

Record locking (2 marks): when a transaction begins updating a record it places a lock on it, so any other transaction must wait until the lock is released before it can read or write that record. This serialises access to the record, so the second transaction works from the already-updated value and no update is lost. Markers reward the read-modify-write overwrite for the problem and "lock forces others to wait" for the fix.