• 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

NX: Locking Scores - 44/80

 
Ranch Hand
Posts: 293
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Lately there have been many locking scores of 44/80. It is currently a big mystery why people are losing a chunk of points here. This url is a recent posting from the Results forum where people are starting to think about why these points could be lost.
From what I have seen in the postings, both Max and Phil are thinking about this. Phil suggested we start a separate thread on the topic, so here it is.
Ideas anyone?
TJ
 
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Terry,
It seem to me that it is not because of the Wait and NotifyAll. Could it because of how the lock cookies are generated as discussed in this
thread.
Just a wild guess.
Best Regards
 
Terry Martinson
Ranch Hand
Posts: 293
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frankie -
I checked out that thread you mentioned.
It talks about the different ways we can generate a lock cookie.
1. random.nextLong() (using statically held random, NOT new random each time)
2. System.currentTimeMillis()
3. new Date().getTime()
4. static long seeded with 1, increment it by 1 on every lock attempt
I currently do the random.nextLong() approach - #1.
Do folks think this might be the problem? If so, I may change to #4.
TJ
[ January 27, 2004: Message edited by: Terry Martinson ]
 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
is there anyone out there who scored higher than 44/80?
maybe if people with higher marks shared their design, we could see the difference...
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Terry,
About the lock cookies generation, I just completed the thread mentioned above.
What you currently do is perfect IMO. I wouldn't change it.
Best,
Phil.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi everybody,
James, Ken Krebs passed with 389/400. Unfortunately, he didn't write there the points breakdown. But as he lost only 11 points out of 400, we may guess that his locking was OK.
Last night, I quickly checked Damu's locking code in this thread. Unfortunately (though appropriately ), the code has been removed in the meantime.
What I can say is that his lockRecord()/unlock() methods pair looked correct.
So it let me think of other possible issues :
  • The way lock cookies are generated (see my comment just above). But alone, it cannot explain a loss of 36/80 points !
  • The way locking is checked/ensured in the updateRecord() and deleteRecord() methods (Damu didn't post anything on that).
  • The way unlock() calls are ensured or not : lock/unlock sequences ideally should be part of a try/finally construct.
  • Deadlock detection or not : deadlocks due to crashed clients or crossed multiple locks claims.


  • For the latter, I know that most of the people here pretend that deadlock detection is optional. But I still think that it could make the difference between a maximum score for locking and an average one. After all, the simplest possible locking code can be coded in less that 20 lines. Isn't it too "lightweight" to deserve 80 points ? I really don't know, and I guess that it may depend on the grader assigned to you.
    In the SCJD part of her great SCJP book, Kathy Sierra writes: "Your locking design and implementation decisions (and execution) are the most important parts of your Developer assignment" (p.637). She also explicitly mentions deadlock detection (p.640).
    Best,
    Phil.
     
    Philippe Maquet
    Bartender
    Posts: 1872
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Nicolas (44/80 for locking also) just gave us a few clues about his locking scheme here.
    I copy and paste the locking part of his post :

    5. For the Locking part, I do NOT specify the functions provided in the SUN interface as synchronized in order to avoid the chances for auto fail. Instead, I perform synchronization for each function. I used Vector as the locker. Maybe this makes me lost points, however, some people who use HashMap results the same as me. I do check whether the record is locked before each access, and I do notify all threads after the lock operation(lock and unlock) completes. I really wonder why so many people score 44/80 in this part, I have sent an email to SUN about this issue.


    Regards,
    Phil.
     
    Ranch Hand
    Posts: 451
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Phil, I did state at the beginning of my design discussion thread that ALL 11 of my deducts were under General Considerations. I reprise the locking portion below.


    Locking
    ======
    The implementation of the Services book method in ServicesImpl is the only user of the locking API. I specified a contract in the Javadoc that calls for any potential users of the locking API to invoke lock/process/unlock as a sequence within the context of a single method call which guarantees it will happen within a single thread of execution. When lock is invoked, a check is made to see if the Contractor already has been locked by another thread. If it has, the current thread will wait until notified that it has been unlocked. If not, a Lock object is created that has a reference to the current thread and it is put in the locking Map with the Contractor as the key. The protected processing operation is performed and then the Lock is removed from the Map and destoyed by the unlock method call. It is vital that any exception that occurs during processing is caught and rethrown after the Contractor has been unlocked. Deadlock is prevented by specifying a locking order to be used by programmers.


    A few points regarding why I think I got no deductions in this section:
  • Deadlock prevention - Design By Contract

  • I think that the 3-tier design was essential in this being a successful strategy. By taking this approach, I can state (in the Javadoc for the Data implementation) a clear and detailed specification of a locking contract that has to be followed by any programmer that wants to use the locking API. The gui client simply uses some implementation of Services and doesn't have to be concerned with using the locking API or the Data class at all. Specifying the locking order for the contract was mandatory. There are of course other approaches that will work.
  • Locking cookie

  • I was lucky in that I didn't need to create one; i.e. one less thing to go wrong. My instructions allowed me to bind directly to the invoking thread which was really easy. If you get a deduct here, you are probably tried to do too much and had a hole in your unique cookie logic. There is a really simple solution if you need to make a cookie that is unique (within the server's JVM), but I don't want to spoil all the fun.
  • Excessive synchronization

  • Avoid it. If you put it everywhere just in case, the tester will know that you don't know what you're doing. Only synchronize where you need to be protected from concurrent non-atomic access to mutable data. And do use the synchronized wrappers that are available for the collections API. I believe you can use the legacy versions where you need synchronized collections without penalty. If they give out deducts for that, they should also scold the Swing development team for not providing support for them.

    Hope this helps.
    [ January 27, 2004: Message edited by: Ken Krebs ]
     
    Ranch Hand
    Posts: 286
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi,
    Part 1
    ------
    Hi Ken. You passed with a great score of 389/400. I'll make a guess that
    Joshua Bloch's "Effective Java" has been an integral part of your Java
    development, and if not, then it played an important role for this exam?
    I make this guess in that I've read the book, and looked at certain sections
    more than once when they were applicable to a project. However, now that I am
    working on this exam which touches upon more aspects of Java, and now that I've
    read and written in this group, I am beginning aware that, in my opinion,
    Bloch's book would very likely be essential to passing (though I'm not saying
    that it's the only book that may be essential).
    Part 2
    ------
    In a previous, related thread, I noted that Andrew, in the past, has asserted,
    correctly, that for as much as possible, you do not want to lock down the
    complete database, either implicitly or explicitly. I also noted that I wasn't
    sure that using a synchronized collection was all that bad given the speed of
    in-memory operations.
    I speculate, or propose as a theory, that the major differences between those
    losing 20 to 30 points, and those not, is that for those that did lose the
    points, somewhere in their design, either implicitly or explicitly, the whole
    database was locked down.
    You all, of course, would need to verify this.
    I am not saying that any of the comments made above in this great thread are
    equally not important, they may be; and, I appreciate these finer points of
    locking and unlocking that were enumerated above (though I don't, at this
    time, necessarily understand all of them at this time due to my limited
    experience).
    Part 3
    ------
    Here are some quotes or summaries from Bloch's book, though I would have
    no way of knowing whether the examiners are in tune with Bloch, though I
    personally hope that they are, since I will be using Bloch's advice as my
    bible.
    I will not go into an explanation of every short summary.
    1. Avoid too much use of synchronization (a point Ken just made above).
    1a. Avoid deadlock risks: never call out to a foreign controller (object)
    from within a synchronized block.
    1b. When you're working within a synchronized block, do as little as possible
    and then release the lock (Andrew also spoke to this in response to some of
    my previous posts).
    1c. Document the "thread-safety" aspects of your class.
    1d. "One reason to synchronize a class internally is because it is intended
    for heavily concurrent use and you can achieve significantly higher concurrency
    by performing internal fine-grained synchronization. For example, it is
    possible to implement a non-resizable hash table that independently synchronizes
    access to each bucket. This affords much greater concurrency than locking the
    entire table to access a single entry."
    I added italics on Bloch's word: "significantly." And, this remark is what I
    propose may lose 20 points, though it is only speculation; that is, you lose the
    points if you implement a collection such that when you operate on one element
    (or record), you lock the complete collection. Ken probably can confirm that he
    did not do this, he did not lock a complete collection to operate on
    one element or record.
    2. Document thread safety. [Bloch then expands on this for three pages.]
    Thanks,
    Javini Javono
     
    Ken Krebs
    Ranch Hand
    Posts: 451
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Javini,
    I do have a copy of Effective Java which I ruse from time to time but I don't think I used it more than a little bit for the assignment. The most important book for me while working on this was Max's. Effective Java is well worth reading though.


    1a. Avoid deadlock risks: never call out to a foreign controller (object)
    from within a synchronized block.


    Bloch's point is to be careful of ceding control within a synchronized block to code you have no control over, possibly in some overriden method.


    Ken probably can confirm that he did not do this, he did not lock a complete collection to operate on one element or record.


    Correct.
    [ January 27, 2004: Message edited by: Ken Krebs ]
     
    Ranch Hand
    Posts: 319
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Ken.


    I specified a contract in the Javadoc that calls for any potential users of the locking API to invoke lock/process/unlock as a sequence within the context of a single method call which guarantees it will happen within a single thread of execution.


    Did you also add this to the javadoc of the sun provided interface? Or only in your implementing class.
    There are lot's of things, including this, that I think any user of the DBAccess interface should know if they use my implementation of it.
    So my question is, should things like the locking contract, and the runtime exceptions thrown by my implementation, be documented in the DBAccess interface as well? Or is it fine to have that in my implementing class only? Since there might be other implementations of DBAccess that are different.
    Jacques
     
    Ken Krebs
    Ranch Hand
    Posts: 451
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    This contract, and the runtime exceptions noted, are implementation details and apply only to my, specific implementation of DBMain. There is an implication in the instructions that there may be another implementation of DBMain in the reporting application. I have no control over that implementation and therefore cannot impose any additional contractual obligations on it. It would be very wrong and futile to try to do so.
     
    Jacques Bosch
    Ranch Hand
    Posts: 319
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Good. Thanx for settling my mind on that.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic