• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

locking in Denny's DVDs example

 
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Question 1
==========
The "Denny's DVDs" example in the SCJD book by Habibi et. al. uses a static vector (reservedDVDs) to hold the primary keys of all the locked records.
The methods that lock and unlock a record are shown below:

public void reserveDVD(String upc) throws InterruptedException{
synchronized(reservedDVDs){

//if the record is already locked, then wait
//until it is released.
while( reservedDVDs.contains(upc) ){
reservedDVDs.wait();
}
reservedDVDs.add(upc);
reservedDVDs.notifyAll();
}
}

public void releaseDVD(String upc){
synchronized(reservedDVDs){
reservedDVDs.remove(upc);
reservedDVDs.notifyAll();
}
}

My question is what is the point of calling notifyAll() in the locking method? It is obvious why you need to notify after unlocking a record, but I don't understand the point of notifying after locking a record.

Question 2
==========
The methods shown above belong to DVDDatabase. This class also contains methods to read, and modify records, and all public methods of this class are synchronized. Clients are not given a reference to DVDDatabase directly, but an adapter class, DVDDbAdapter. Each method of the latter:

- calls reserveDVD() for the relevant record
- reads a the record
- possibly modifies the record
- calls releaseDVD() for the record

Given that clients are only able to access the datatabase via DVDDbAdapter, I don't understand why the methods of DVDDatabase need to be synchronized. For example, the following method of DVDDatabase is provided for returning rented DVDs:

public synchronized boolean returnRental(String upc) throws
IOException,
ClassNotFoundException
{
boolean retVal = false;
try {
DVD dvd = getDVD(upc);
if (dvd != null){
dvd.setRented(false);
retVal = modifyDVD(dvd);
}
}
catch (Exception e){
System.err.println(e.getMessage());
}
return retVal;
}

Clients cannot call this method directly, but instead must call this corresponding wrapper method of DVDDbAdapter (db is an instance of DVDDatabase):

public boolean returnRental(String upc) throws IOException,
ClassNotFoundException,
InterruptedIOException {
try{
db.reserveDVD(upc);
boolean retval = db.returnRental(upc);
db.releaseDVD(upc);

return retval;
}
catch(InterruptedException ie){
ie.printStackTrace();
}
}

So before the synchronized returnRental() method of DVDDatabase is called, the record must already bev locked, so why does this method need to be synchronized?

My guess is that the authors just wanted the DVDDatabase class to be thread-safe despite the fact that it can't be used directly, but I may be missing something?

Thanks in advance,
Dan (SCJP)
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Dan,

My question is what is the point of calling notifyAll() in the locking method? It is obvious why you need to notify after unlocking a record, but I don't understand the point of notifying after locking a record.



About 18 months ago Jim Yingst, Phil Maquet and I were discussing this with Max (Mehran) Habibi. From memory, Max said that there was something they were planning with the DVD application which could result in two separate wait calls - in which case there would be value in notifying the threads waiting. Sorry, I don't remember the exact details, but the major players are listed, along with the time frame - you may be able to find the topic using the search function of this forum.

It is not possible to make the assignment in a book exactly the same as the Sun SCJD assignment. The usual way to handle this is to change some of the requirements - adding or removing complexity in different areas. This idea of two calls to wait on a single object might have been one such change.

Regardless, it is not needed for the Sun SCJD assignment - all you need is the single call to wait, along with a single call to notifyAll in the unlock method (or, depending on your solution, a single call to notify).

My guess is that the authors just wanted the DVDDatabase class to be thread-safe despite the fact that it can't be used directly, but I may be missing something?



From memory (again) I think the authors were originally planning on having multiple threads running on the DVDDatabase class, however this may have changed at a later date.

Regards, Andrew
 
Dan Murphy
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your reply Andrew,

If I understand you correctly, then you agree that

- there is no need to call notify() after locking
- the DVDDatabase methods do not need to be synchronized

Of course, if the requirements were to change, or features were addded, these statements could become false, but it seems they are true of the code as presented in the book?

Cheers,
Dan
 
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dan Murphy:
Thanks for your reply Andrew,

If I understand you correctly, then you agree that

- there is no need to call notify() after locking
- the DVDDatabase methods do not need to be synchronized

Of course, if the requirements were to change, or features were addded, these statements could become false, but it seems they are true of the code as presented in the book?

Cheers,
Dan



Hi Dan,

The call to notfiyall on pp. 129, line # 9, is there to assist the thread that might be waiting to lock the entire DB. This is a requirement in the SCJD version that existed when the book was written: FBN. A given client had to be able to lock the entire database.

Of course, this is practically impossible when other clients are actively locking records in the database, so we need a mechanism to tell the individual record-locking clients to knock it off after a given client has tried to lock the entire DB(by issuing a call to lock record # -1).

The notfiyall call on p.129, line #9, is there to help with this conundrum. This call allows new clients who are attempting to reserve a DVD to become aware of the fact that a request for record # -1( the 'lock the entire db record'), has been issued, and they should not attempt to achieve a lock on their own record.

Now for your question on the DVDDatabase methods. The methods do need to be synchronized, if you have a system set up, per figure 4-14, p. 127. The discussion on pgs. 127explores this. The following discussion, on p.128, discusses the fact that the system will work for either setup: figure 4-13 or figure 4-14. Yes, the current system in the book is set as per figure 4-13, and that's explained in the second paragraph of page 127.


Perhaps we didn't explain all of this as well as should have: I can certainly see where your questions are reasonable. But we were struggling with giving the reader hints on what approach to take without giving away the entire assignment, and thus robbing you of your own ingenuity. This might have been one of the cases where we could have provided better explanations.

HTH,
M
[ March 31, 2005: Message edited by: Max Habibi ]
 
Dan Murphy
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator



The call to notfiyall on pp. 129, line # 9, is there to assist the thread that might be waiting to lock the entire DB. This is a requirement in the SCJD version that existed when the book was written: FBN. A given client had to be able to lock the entire database.



Hi Max,

Thanks for getting back to me! So if I understand you correctly, the notifyAll() call is redundant in the absence of a requirement that a client has to be able to lock the entire database?



Now for your question on the DVDDatabase methods. The methods do need to be synchronized, if you have a system set up, per figure 4-14, p. 127. The discussion on pgs. 127explores this. The following discussion, on p.128, discusses the fact that the system will work for either setup: figure 4-13 or figure 4-14. Yes, the current system in the book is set as per figure 4-13, and that's explained in the second paragraph of page 127.



I think I see what you mean...are you saying that if the clients could get a reference to DVDDatabase it would still be thread-safe because its methods are synchronized. In this case they would be sychronizing on the DVDDatabase instance itself, rather than reservedDVDs. Is this correct?

Great book by the way!
- Dan
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Thanks for getting back to me! So if I understand you correctly, the notifyAll() call is redundant in the absence of a requirement that a client has to be able to lock the entire database?


Oh boy, now you're going to make me think. Yes, I believe so...though I'm sure that someone will now point out how it's not redundant at all and make a jackass out of me


I think I see what you mean...are you saying that if the clients could get a reference to DVDDatabase it would still be thread-safe because its methods are synchronized.
Great book by the way!
- Dan
Yep! You're got it.


Great book by the way!
- Dan

Don't tell me, follow my signature and write a review

All best,
M
 
And inside of my fortune cookie was this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic