C H A P T E R
14
Transactions
Practice Exercises
14.1 Answer: Even in this case the recovery manager is needed to perform
roll-back of aborted transactions.
14.2
Answer: There are several steps in the creation of a file. A storage area
is assigned to the file in the file system, a unique i-number is given to the
file and an i-node entry is inserted into the i-list. Deletion of file involves
exactly opposite steps.
For the file system user in UNIX, durability is important for obvious rea-
sons, but atomicity is not relevant generally as the file system doesn’t
support transactions. To the file system implementor though, many of the
internal file system actions need to have transaction semantics. All the
steps involved in creation/deletion of the file must be atomic, otherwise
there will be unreferenceable files or unusable areas in the file system.
14.3 Answer: Database systems usually perform crucial tasks whose effects
need to be atomic and durable, and whose outcome affects the real world
in a permanent manner. Examples of such tasks are monetary transac-
tions, seat bookings etc. Hence the ACID properties have to be ensured. In
contrast, most users of file systems would not be willing to pay the price
(monetary, disk space, time) of supporting ACID properties.
14.4
Answer: If a transaction is very long or when it fetches data from a
slow disk, it takes a long time to complete. In absence of concurrency,
other transactions will have to wait for longer period of time. Average
responce time will increase. Also when the transaction is reading data from
disk, CPU is idle. So resources are not properly utilized. Hence concurrent
execution becomes important in this case. However, when the transactions
are short or the data is available in memory, these problems do not occur.
14.5
Answer: Most of the concurrency control protocols (protocols for en-
suring that only serializable schedules are generated) used in practice are
based on conflict serializability—they actually permit only a subset of
1
评论0