Transactional Isolation - Transaction Processing - page 119

database when executed alone in the absence of system crashes. The concurrency
control of the database management system enforces the actions of concurrently
running transactions to be executed according to such a history in which each
transaction runs at its prescribed isolation level.
Concurrency control can be termed either pessimistic or optimistic. In pessimistic
concurrency control , an action by a transaction is allowed to be executed only when
it cannot cause an isolation anomaly. Pessimistic concurrency control is typically
enforced by locking : to execute an action, a transaction must acquire a lock that
prevents disallowed isolation anomalies from occurring.
In optimistic concurrency control , transactions are allowed in their forward-
rolling phase to perform dirty or unrepeatable reads and even dirty writes on
data-item copies stored in private workspace. When a transaction is about to
commit, that is, executing the C action, the system validates the transaction by
checking whether or not any disallowed isolation anomalies have occurred; if so,
the transaction is aborted and rolled back; otherwise, the transaction is allowed to
commit (and the updates stored in private workspace installed into the database).

Problems

5.1 We use the concept of a transaction history to model the execution order of the
actions of concurrently running transactions. However, this modeling is not accurate
because it does not observe what actually happens at the physical database level. For
example, even if we say that an action IŒx; v by transaction T 1 is executed before
an action RŒy; w by transaction T 2 , it may very well be that the executions of these
two actions are interleaved when seen as sequences of physical actions on pages,
such as traversals of root-to-leaf paths in a B-tree. Explain why it still makes sense
to say that IŒx; v is executed before RŒy; w , and not vice versa.

5.2 Explain why an unmodified page can contain dirty data items and why all the
data items in a modified page can be clean (i.e., non-dirty).

5.3 The integrity constraint on the database states that a tuple with key value x can
appear in the database if and only if the tuple .y; 1/ appears in the database. Are the
transactions of the form

T 1 D BD Œx; u DŒy; aI Œy; 0C and

T 2 D BI Œx; v DŒy; bI Œy; 1C
logically consistent with respect to the integrity constraint? Consider the following
history:

T 1 W BD Œx; u DŒy; 1I Œy; 0C

T 2 W BI Œx; v DŒy; 1I Œy; 1C