Question: Locking is not done explicitly in persistent programming
Locking is not done explicitly in persistent programming languages. Rather, objects (or the corresponding pages) must be locked when the objects are accessed. Most modern operating systems allow the user to set access protections (no access, read, writes) on pages, and memory access that violate the access protections result in a protection violation (see the Unix mprotect command, for example). Describe how the access-protection mechanism can be used for page-level locking in a persistent programming language.
Answer to relevant QuestionsIn timestamp ordering, W-timestamp (Q) denotes the largest timestamp of any transaction that executed write (Q) successfully. Suppose that, instead, we defined it to be the timestamp of the most recent transaction to execute ...Consider the validation-based concurrency-control scheme of Section 16.3. Show that by choosing Validation (Ti), rather than Start (Ti), as the timestamp of transaction Ti, we can expect better response time provided that ...Devise a timestamp-based protocol that avoids the phantom phenomenon.Compare the shadow-paging recovery scheme with the log-based recovery schemes in terms of ease of implementation and overhead cost.Why is it relatively easy to port a database from a single processor machine to a multiprocessor machine if individual queries need not be parallelized?
Post your question