CPSC 310 HW 6, Summer 2008, Ronnie Ward
Assigned 7/16/08, DUE in class on 7/23/08
Turn in a hardcopy with the Assignment Cover page and post your solutions to CSNet
These exercises were selected from Chapter 8 and 12, and from SimpleDB to help you
better understand transactions, storing data in records, representing tables, and indexing
in SimpleDB. Answers in RED.
1. The get/set methods in the SimpleDB Transaction class obtain a lock on the specified
block. Why don’t they unlock the block when they are done? Essentially, every
transaction all lock requests precede all unlock requests (see two-phase locking, p. 936 of
the textbook). A SimpleDB transaction releases all its locks when it commits or
rollsback. It should not release any locks prior to finishing. All SimpleDB transactions
obey this two-phase locking protocol, so that concurrent transactions will not conflict
with one another. That is, the transactions are serial (see p. 399 of the textbook). Also,
see Assuring Serializable Behavior on p. 400 of the textbook.
2. Explain why the Transaction class method nextTxNumber is synchronized. What
could happen if it were not? Is it a problem for the other methods in that class to not be
synchronized? Explain your answer. The method is called by a transaction constructor to
obtain a unique transaction number. If the method were not synchronized, then two
concurrent transaction constructors could interleave their execution in such a way that
both are assigned the same transaction number. The method is synchronized to prevent
this from happening.
3. 12.2.5, p. 578. Also calculate the wasted space in each situation.
For parts (a) and (b), the header takes 40 bytes, while for (c) it takes 80 bytes. The
calculations are thus:
a) (4096-40)/44 = 92.
b) (4096-40)/52 = 78.
c) (4096-80)/72 = 55.
Yue will provide the wasted space results. The waste space is computed as follows:
a) (4096-40)/44 = 92.
Waste: Only the left over part: 4096-40-44*92=8
b) (4096-40)/52 = 78.
Waste: inside the record because of fields starting position: 78*8=624.
No left over waste.
c) (4096-80)/72 = 55.
Waste: inside of the record: 55*28=1540, block head: 40, left over:
4096-80-72*55=56
Total waste: 1540+40+56=1636
4. Revise the classes RecordFile and RecordPage to support a previous() method, and
revise the RecordFile class to support a method named afterLast(), which positions the
current record to be after the last record in a file. Modify the TestRecordMgmt.java (see
website for lecture on 7/14/08) program to print the movies table in reverse order. This
problem was suggested by Ed Sciore:
http://www.cs.bc.edu/%7Esciore/courses/cs357/hw6.html
10 records were inserted into the movie table and the forward and backward listings
created by the following code change to TestRecordMgmt.java.
