• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Common Concepts in Solving Locking Problem

 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
In the DBMain Java interface, different recent project assignments have
slightly different interfaces. For instance:
public void lock(int recNo) throws ...
public int lock(int cookie) throws ...
I have not looked back at the posts to see if the second one really is:
public int lock(int recNo, int cooke) throws ...
but, you get the idea.
Assume for this question that you are dealing with a physical
random access file and you are not holding the file
in an object in memory.
Question: even though the signatures provided by Sun
on these different exams are somewhat different,
basically the locking and unlocking schemes are, from a
conceptual standpoint, pretty similar? That is, if one method
is missing something in the argument list, then it needs to
supply this something by sharing an object with the caller.
So, the method signatures are there to introduce a little
bit of variety, but the core work that needs to be done is
essentially the same, as long as the general thrust of the
solution is the same (such as using wait() and notifyAll())?
To say it another way, if one software developer with a standard
way of applying patterns and solutions took two slightly
different tests, the core solution what be remarkably similar
in both tests, even though the method signatures varied
slightly.
Thanks,
Javini Javono
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini,

Question: even though the signatures provided by Sun
on these different exams are somewhat different,
basically the locking and unlocking schemes are, from a
conceptual standpoint, pretty similar? That is, if one method
is missing something in the argument list, then it needs to
supply this something by sharing an object with the caller.
So, the method signatures are there to introduce a little
bit of variety, but the core work that needs to be done is
essentially the same, as long as the general thrust of the
solution is the same (such as using wait() and notifyAll())?
To say it another way, if one software developer with a standard
way of applying patterns and solutions took two slightly
different tests, the core solution what be remarkably similar
in both tests, even though the method signatures varied
slightly.

Yes. In my implementation, I follow Max's approach that I use Vector as the lock holder. I even do not consider the cookie issue (since my API from DBMain does not require this).
Some people use HashMap to store the lock, but, does it really necessary? Since only one thread can lock one record at one time, so I decide not to complicate the system (such as using a LockManager). But I believe, even we need to add a cookie to it, we can simply change the lock holding part, without changing the core algorithm.
Nick.
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my implementation, I follow Max's approach that I use Vector as the lock holder. I even do not consider the cookie issue (since my API from DBMain does not require this). Some people use HashMap to store the lock, but, does it really necessary?
There is not a single reason that one should use a legacy collection, such as Vector or Hashtable, for lock holder or for anything else, and there are many reasons why it could cause harm. Sun itself encourages the developers to use the classes that are naturally part of the collections framework, rather than the classes that have been retrofitted to it, and I would take that encouragement seriously.
 
Ken Krebs
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Eugene,
You're right of course. Now if only we could get Sun to convince the Swing team of that.
JTable, DefaultTableModel, JComboBox, DefaultComboBoxModel, JList, JTree all use Vector in their public interface and there may be more. They could at least support List in addition to Vector. It couldn't hurt to get rid of some of that unneeded synchronization.
DefaultTableModel and DefaultTableColumnModel even have protected Vector fields! I was suprised to find a lot of protected data fileds in Swing. ARGH

At least SpinnerListModel uses List instead of Vector but that's fairly new.
I'm sure that there are many more uses of the legacy collections internal to some of these classes.
I have to admit I used Vector in my submission but it was only to make using DefaultComboBoxModel easier.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Nick,
I'd like to add to what Eugene wrote above that as Vector being synchronized internally and you need some external synchronization anyway for wait() / notifyAll() purposes, that double synchronization adds useless overhead.
Another benefit of HashMap (but it would be the same in comparison with an ArrayList) is speed in searching. Unless you index your Vector by recNo, you'll have to use the contains() method which performs a linear search (less efficient than HashMap.containsKey()).
Regards,
Phil.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic