Exercises To Chapter 15 - Transactions
Exercises To Chapter 15 - Transactions
15.2. Suppose that there is a database that never fails. Is a recovery manager required for
this system?
In the case of software errors in written transaction, or due to the absence of some data,
transactions will be aborted, and they are to be rolled-back
15.3. Consider file system. What are the steps involved in creation and deletion files, in
writing data to files? Explain how the issues of atomicity and durability are relevant to
the creation and deletion of files, writing data to files?
For creation-deletion of file, there must be created/deleted directory entry for this file. In
the case of creation disk clusters are to be allocated to file, in the case of deletion,
allocated clusters are to be deallocated. Data are written to the RAM buffer, from which
they are transferred to disk in the case of overfilling, or when file is closed, or when
buffer is flushed by explicit command.
Durability is important for files – we expect that saved data will be persistent on disk.
Atomicity is not guaranteed for applications, but it must be provided for operations of
deletion and creation, otherwise, we shall lose disk space.
15.4. Database implementers paid much attention to ACID properties, but file-system
implementers have not. Why?
Because database application are crucially to be atomic and durable, violation can cause
real-world problems, hence this job for providing ACID was paid for.
T1
conflict serializable, if respective precedence hasn’t cycles. Presence of cycle means that
there are conflicting instructions which are to be executed at first in each transaction
involved in cycle. This means that in any sequential schedule required sequence of such
conflicting instructions will be violated. Our precedence graph has not cycles, so
respective schedule is conflict serializable. For finding serial schedule, conflict-
equivalent to schedule represented by such precedence graph, we are to determine
sequence of execution of transactions complying to the precedence graph. We can’t take
as 1st transaction to be executed T5 since conflicting instructions of T4, T3 are to be
executed before it. Considering our graph, we come to conclusion that only T1 may be
chosen as the 1st transaction for execution, as not having predecessors. Similarly, 2nd may
be only T2, having T1 as predecessor. Next may be chosen either T3, either T4, each of
them is to be executed both after T1, T2. So, our possible schedules, will be either T1,
T2, T3, T4, T5, either T1, T2, T4, T3, T5, each of corresponds to the topological order
between nodes represented by precedence graph.
For machine processing, graph may be represented by incidence matrix:
1 2 3 4 5
1 1 1 1
2 1 1
3 1
4 1
5
15.11. What is a recoverable schedule? Why recoverability is desirable? Are there any
circumstances in which it would be desirable to allow non-recoverable schedules?
Recoverability assumes ability to recover previous consistent state of database in the case
of transaction failure, so it is important feature. For maintenance of such a feature in
concurrent environment, when multiple transactions execute simultaneously, non-
recoverable situation may occur if transaction T1 which have used results provided by
other transaction T2, will commit, but after that moment T2 will continue execution and
will fail. So, results provided by T2 were already used by T1, and since T1 has
committed this situation can’t be rolled-back. For providing recoverability, each
transaction, which uses results provided by other transactions, must not commit before all
of these transactions will commit. This may lead to large response time for transactions
which use results provided by other long transactions. In the case of such circumstances,
if probability of failure of transactions providing information for other transactions, it
may be allowed to use non-recoverable schedules.
15.12. What is a cascadeless schedule? Why is cascadelessness of schedules is desirable?
Are there any circumstances under which it would be desirable to allow non-cascadeless
schedules?
A cascadeless schedule is one in which failure of transaction results of which are to be
used in other transactions, will not lead to necessity of rolling-back latter transactions.
This is achieved by allowing to read results provided by some transaction, only after
commitment of the latter. This restricts concurrency of execution of transactions, and if
probability of transactions failure is small, it may be desirable to allow non-cascadeless
schedules.