Hi
Alan,
I believe the problem is that even though you have interspersed your rentals and returns, these are threads at the control of the JVM
thread scheduler. So there is no guarantee that a return will happen before a rental.
When I look at the output of a test run with your code, I see:
We start of with lines 1,2 and 3 all returning rentals (since copies in stock are incrementing). Line 4 is our first rental, followed by a return, followed by a rental, followed by several returns.
Skipping forward to line 18 we see a return bringing our copies in stock up to 7. We then follow with 13 returns (up to line 31). However the setRented() method of the DVD class will not allow negative rented numbers:
With the result that lines 26 - 31 show that copies in stock remain at zero. But with the threads returning the DVDs that previously did not exist
the final number of DVDs in stock is very likely to end up greater than the starting value.
A better test would be for DBTester to do both the rental and the return (with a random delay between the rental and the return while holding zero locks), but only returning the DVD if it was allowed to rent in the first place (or alternatively, if it was unable to rent the DVD, wait for a while and try again). DBTestRunner would also have to be modified to accomodate the new DBTester.
I leave these modifications as an exercise for you
.
Regards, Andrew