Hi!
I wanted to start new thread about similar topic, but let do this here...
My assignment is UrlyBird 1.3.2, where I'm tracking lock owner by token.
I have implemented two solutions (still wondering which should I choose):
1st - The simplest locking mechanism with one mutex on Map<Long, Long>. The key is record number, under value I store cookie (random long). Threads are notified by notifyAll()(it has to be notifyAll() please read similar threads). By waking up all thread I'm violating contract ( not always that record will be unlocked which Thread waits for) Other disadvantage may be that it may cause unnecessary CPU burst.
2nd - Hand-Over-Hand, please read Andrew's sample in his great book!

It does not violate contract about "consuming no CPU cycles until the desired resource becomes available", but it's more complex. I see one problem there - locks are added to map but they are never removed. Map may grow and grow to the size equal to number of valid records in db. That's the scalability problem!
I prefer 2nd solution since it's more efficient and does not violate contract. On other hand it looks like SUN does not subtract points if You choose 1st.
I also found in book this sentence
For the SCJD exam, scalability and performance are not design considerations.
. Guys can You confirm that?
So 1st is performance issue, and 2nd scalability.
I think I'll go with 2nd (I like it, except remove()
Did anyone found solution for remove()?
Did anyone decided to go with hand-over-hand and what was final score ?
Regards
Sebastian.