A
Deferred writeback implies that when a transaction modifies a database
attribute, the modification is not written to the database until that
transaction commits. In such a system no transaction can perform dirty
reads, and thus the need for cascade rollbacks is removed. Therefore
cascade rollbacks do not occur in systems which use deferred writebacks.
close B
With immediate writeback, if a transaction updates an attribute in the database
the modification is immediately made to the database image on disk. If another
transaction then reads that information, it is basically reading information
from a transaction which has not yet committed. If the modifying transaction
now aborts, not only does its modifications have to be undone, but the
transactions which have read the modifications will have to be aborted as well.
This may case further aborts, or so called "cascase rollbacks".
close C
There is no such thing in the module notes as a waterfall transaction management
system.
close D
Cascade rollbacks (or in fact any sort of rollback) is the result of aborts,
not commits.
close E
Cascade rollbacks are related to aborts in "immedate update" transaction
management systems. Look again at the possibilities above...
close
In transaction, cascade rollback
- Can occur in systems which use deferred writeback
- Can occur in systems which use immediate writeback
- Occurs in systems which use the "waterfall" transaction management system
- Is a result of simultaneous transaction commits.
- None of the above
|