1516 answer consider two transactions t 1 and t 2

Info icon This preview shows pages 9–11. Sign up to view the full content.

View Full Document Right Arrow Icon
executed, instead of reexecuting the entire transaction. 15.16 Answer: Consider two transactions T 1 and T 2 shown below. T 1 T 2 write (p) read (p) read (q) write (q)
Image of page 9

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
10 Chapter 15 Concurrency Control Let TS( T 1 ) < TS( T 2 ) and let the timestamp test at each operation except write ( q ) be successful. When transaction T 1 does the timestamp test for write ( q ) it finds that TS( T 1 ) < R-timestamp( q ), since TS( T 1 ) < TS( T 2 ) and R-timestamp( q ) = TS( T 2 ). Hence the write operation fails and transaction T 1 rolls back. The cascading results in transaction T 2 also being rolled back as it uses the value for item p that is written by transaction T 1 . If this scenario is exactly repeated every time the transactions are restarted, this could result in starvation of both transactions. 15.17 Answer: In the text, we considered two approaches to dealing with the phantom phenomenon by means of locking. The coarser granularity approach obviously works for timestamps as well. The B + -tree index based approach can be adapted to timestamping by treating index buckets as data items with timestamps associated with them, and requiring that all read accesses use an index. We now show that this simple method works. Suppose a transaction T i wants to access all tuples with a particular range of search-key values, using a B + -tree index on that search-key. T i will need to read all the buckets in that index which have key values in that range. It can be seen that any delete or insert of a tuple with a key-value in the same range will need to write one of the index buckets read by T i . Thus the logical conflict is converted to a conflict on an index bucket, and the phantom phenomenon is avoided. 15.18 Answer: Note: The tree-protocol of Section 15.1.5 which is referred to in this question, is different from the multigranularity protocol of Sec- tion 15.3 and the B + -tree concurrency protocol of Section 15.10. One strategy for early lock releasing is given here. Going down the tree from the root, if the currently visited node’s child is not full, release locks held on all nodes except the current node, request an X-lock on the child node, after getting it release the lock on the current node, and then descend to the child. On the other hand, if the child is full, retain all locks held, request an X-lock on the child, and descend to it after getting the lock. On reaching the leaf node, start the insertion procedure. This strategy results in holding locks only on the full index tree nodes from the leaf upwards, until and including the first non-full node. An optimization to the above strategy is possible. Even if the current node’s child is full, we can still release the locks on all nodes but the current one. But after getting the X-lock on the child node, we split it right away. Releasing the lock on the current node and retaining just the lock on the appropriate split child, we descend into it making it the current node. With this optimization, at any time at most two locks are held, of a parent and a child node. 15.19 Answer: a. validation testforfirst-committer-wins scheme: LetStart( T i ), Commit( T i ) and be the timestamps associated with a transaction T i and the up- date set for T i be update set( T i ). Then for all transactions T k with
Image of page 10
Practice Exercises 11 Commit( T k ) < Commit( T i ), one of the following two conditions must hold:
Image of page 11
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}

What students are saying

  • Left Quote Icon

    As a current student on this bumpy collegiate pathway, I stumbled upon Course Hero, where I can find study resources for nearly all my courses, get online help from tutors 24/7, and even share my old projects, papers, and lecture notes with other students.

    Student Picture

    Kiran Temple University Fox School of Business ‘17, Course Hero Intern

  • Left Quote Icon

    I cannot even describe how much Course Hero helped me this summer. It’s truly become something I can always rely on and help me. In the end, I was not only able to survive summer classes, but I was able to thrive thanks to Course Hero.

    Student Picture

    Dana University of Pennsylvania ‘17, Course Hero Intern

  • Left Quote Icon

    The ability to access any university’s resources through Course Hero proved invaluable in my case. I was behind on Tulane coursework and actually used UCLA’s materials to help me move forward and get everything together on time.

    Student Picture

    Jill Tulane University ‘16, Course Hero Intern