Locking policies: Safety and freedom from deadlock

A database consists of ellliflc.\' yvhich reLlte to each other in certain ways, i,e., they satisfy cerltlin cOllsistency constraints. Many tinles, when a user updates the database, he nlay have to update tcnlporarily these constraints in orde r tC) eventuaII y t I'an s1'0 I' 111 the database in to a new, consis ten t stat C . For this I'eas 0 n, at 0 nl ic act ion s by the sa nlC user arc grou ped toget her into un its of consistency called transactiolls. In practice. a transaction nlay be either an interactive session, or the execution of a user update progranl. When, however, nlan y' transactions access and update the SanlC database cOI1curTently, there rnust he sonle kind of coordination to ensure that the resulting sequence of interleaved atonlic actions (or schedule) is correct. This TlleanS that all transactions have a consistent view of the data. and furthernlore the database is Icft at the end in sonle consistent state, This required coordination is achic\cd via the COIlcurrency cOlltrol,nechalllsfn ()f the database. ('onsiderahle research effort has heen devoted recently to the theoretical aspects or the design of such a systenl !ECiLTl. SLR, SK, KS, Pa, PBR, KPI. The theory of databasc concurrency control bears a superficial silllilarity to the () pe ra ting systenl Sinspi I'ed con cLI rrency 1he 0 I'Y [K [vI, (' [) 1. The difference is lhtl{ in operating systeIllS \\le have cooperating, Ill0nitoring. dnd 1110n itored. processes, and the goal is to prevent had cooperation or Tllanagenlent (e.g. indetcrnlinacy. deadlocks) In databases, we have a population of' users that arc una\\'are of each other's pres-