Transactions-Concurrency Problems When processing shared data a number problems occur if updates to the database are carried out at the same time by different processes. These problems exist even if updates are packaged as transactions. Transaction processors must be able to deal with interleaved transactions i.e. transactions processed in parallel So, transaction processors have mechanisms that address the problems presented here. It is important to be aware of these problems if a transaction processor is not used.

Lost Update Problem (Examples taken from Begg and Connolly) Update bank balance. Transaction T1 and T2. Bank balance at start =100 T2 reads bank balance (100) T2 Increases bank balance by 100 T1 reads bank balance (100) T2 writes new value of balance to database (200) T1 decrements bank balance by 10 T2 commits T1 writes bank balance to database (90) T1 commits 100 added by T2 is lost. Final balance is 90 Prevented by not allowing T1 to read balance until T2 commits

Uncommitted Dependency-’Dirty Read’ Transactions T1 and T2. Balance start value =100 T2 reads bank balance (100) T2 increments balance by 100 T2 Writes value to database (200) T1 Reads balance (200) T1 Decrements balance by 10 T2 Rollbacks for some reason-transaction failure (100) T1 writes value to database (190) T1 commits Balance now incorrect (190 vs 90) Prevented in same way as ‘lost update’

Inconsistent Analysis Problem This is very similar to previous problems except the transactions are dealing with multiple values (multiple balances). One transaction may be analysing the figures-doing statistics and summaries. While the transaction is reading values from the database (before analysis) another transaction(s) updates some of the balances. e.g. analysis transaction reads two from five balances, then another transaction updates the remaining three, the analysis transaction then reads the three new values. The analysis transaction will not have a consistent set of values. Three of the values were different at the time the first two were read.

Nonrepeatable (Fuzzy) Read A transaction reads a value from data base more than once, but another transaction changes the value between successive reads.

Phantom read Transaction reads a number of records from the database Then reads again but in the meantime a transaction has added records to the database

Summary There are potentially serious problems with concurrent transactions operating on shared data. A transaction processor should be able to run transactions in parallel and avoid concurrency problems. If developing non-transaction based applications that use shared data these problems and the solutions to them should be borne in mind.

These problems are enhanced when using distributed database systems and new very challenging problems arise. e.g. consider replicated databases where copies or part-copies of the database exist in different physical locations.