5. Show that the two-phase locking protocol ensures conflict serializability,and that transactions can be serialized according to their lock points. Answer


Answer: In the concurrency control scheme of Section 16.3 choosing Start



Download 447.03 Kb.
View original pdf
Page4/13
Date08.04.2022
Size447.03 Kb.
#58573
1   2   3   4   5   6   7   8   9   ...   13
nanopdf.com 151-show-that-the-two-phase-locking-protocol-ensures-conflict
Answer: In the concurrency control scheme of Section 16.3 choosing Start(Ti) as the timestamp of Ti gives a subset of the schedules allowed by choosing Validation(Ti) as the

timestamp. Using Start(Ti) means that whoever started first must finish first. Clearly transactions could enter the validation phase in the same order in which they began executing, but this is overly restrictive. Since choosing Validation(Ti) causes fewer nonconflicting transactions to restart, it gives the better response times.
15.14 For each of the following protocols, describe aspects of practical applications that would lead you to suggest using the protocol, and aspects that would suggest not using the protocol

Two-phase locking.

Two-phase locking with multiple-granularity locking.
• The tree protocol.
• Timestamp ordering.
• Validation.

Multiversion timestamp ordering.

Multiversion two-phase locking.
Answer:
• Two-phase locking Use for simple applications where a single granularity is acceptable. If there are large read-only transactions, multiversion protocols would do better. Also, if deadlocks must be avoided at all costs, the tree protocol would be preferable.
• Two-phase locking with multiple granularity locking Use for an application mix where some applications access individual records and others access whole relations or substantial parts thereof. The drawbacks of PL mentioned above also apply to this one.
• The tree protocol Use if all applications tend to access data items in an order consistent with a particular partial order. This protocol is free of deadlocks, but transactions will often have to lock unwanted nodes in order to access the desired nodes.
• Timestamp ordering Use if the application demands a concurrent execution that is equivalent to a particular serial ordering (say, the order of arrival, rather than any serial ordering. But conflicts are handled by rollback of transactions rather than waiting, and schedules are not recoverable. To make them recoverable, additional overheads and increased response time have to be tolerated. Not suitable if there are long read-only transactions, since they will starve. Deadlocks are absent.
• Validation If the probability that two concurrently executing transactions conflict is low, this protocol can be used advantageously to get better concurrency and good response times with low overheads. Not suitable under high contention, when a lot of wasted work will be done.
• Multiversion timestamp ordering Use if timestamp ordering is appropriate but it is desirable for read requests to never wait. Shares the other disadvantages of the timestamp ordering protocol.
• Multiversion two-phase locking This protocol allows read-only transactions to always commit without ever waiting. Update transactions follow PL, thus allowing recoverable schedules with conflicts solved by waiting rather than rollback. But the problem of deadlocks comes back, though read-only transactions cannot get involved in them. Keeping multiple versions adds space and time overheads though, therefore plain PL maybe preferable in low conflict situations.


15.15 Explain why the following technique for transaction execution may provide better performance than just using strict two-phase locking First execute the transaction without acquiring any locks and without performing any writes to the database as in the validation- based techniques, but unlike the validation techniques do not perform either validation or writes on the database. Instead, rerun the transaction using strict twophase locking. (Hint Consider waits for disk IO)

Download 447.03 Kb.

Share with your friends:
1   2   3   4   5   6   7   8   9   ...   13




The database is protected by copyright ©ininet.org 2024
send message

    Main page