• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Single table / Simple Locking - WeakHashMap vs WeakReferences II

 
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all, (Phil, if you can answer that would be great as the question was regarding your code. Thanks. Gave the same subject as yours to let you know about this thread.)
Guys, I got question in the following thread. Bascially that thread was too long and thought will start a new thread for that.
Single table / Simple Locking - WeakHashMap vs WeakReferences
Actually, I got a question for Phil in his sample code. If anyone can please clarify this, that would be great. Thanks.
I am posting the code here from the link for discussion:

I got a question, Phil. In the unlock method, are'nt we supposed to unregister the weakreference that has been registered with the refQueue in lock method.
I was thinking that we should add a refQueue.remove statement in the unlock method to unregister the registered object. Please correct me if I'm wrong. Thanks.
 
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
Hi Satish,
I'm probably going to steer clear of this thread: however, my two cents on the topic is this.
Don't bother with this sort of clean-up issues.
It's not part of your requirement. If you implement it brilliantly, you've receive zero extra consideration. However, if you make the slightest mistake, you'll be penalized. It is, quite simply, a sucker's bet.
If you really, really just want to implement it, then do so after you submit, so it doesn't interfere with your chances of passing. You'll still get the aesthetic pleasure and learning experience, but you won't incur any of the risk.
This is just my opinion. You are, of course, free to do as you see fit.
Best regards,
M
[ March 30, 2004: Message edited by: Max Habibi ]
 
Satish Avadhanam
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Max for your suggestion. I was skeptical not to do in the beginning, but my big Bro. wants me to learn both the safe server shutdown and client crash issues to be dealt cleanly. So only trying to learn.
But as you said, if I mess up anywhere anything, then the chances of pass are low I can implement and learn these issues but not include in the project. Many thanks for the suggestion. Will stick to that.
Phil, as Max said, I will not include this in the project. But I am very much interested to know how we can deal this issue. The issue I was pointing toward unregistering is that becasue in the lock method, you are registering the object to the queue. But you are not clearing/removing the object from the queue. So what I am guessing is in the unlock method also once you remove the weakreference, though the key/value pair is removed from the lockedrecords, it will be still registered to the queue. And so as there is no reference to the weakreference now, whenever it gets garbage collected or about to, it will be added to the refqueue. So what I was thinking is we are supposed to remove/unregister the weakreference from the refqueue while removing the key/value pair in the unlock method. Maybe remove in RQ is not a good method as it will only remove the next available reference from the queue. I think clear from Reference should be exact to use in the unlock method to unregister it. What do you think, Phil? Am too crazy or reasonable thinking is going on?
Thanks for the comments.
Max, if you could also just clear things up, that would be really great. (Not in the exam point of view, but as a learning tool. Thanks)
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Satish,

Phil, as Max said, I will not include this in the project. But I am very much interested to know how we can deal this issue. The issue I was pointing toward unregistering is that becasue in the lock method, you are registering the object to the queue. But you are not clearing/removing the object from the queue.


Max's position is very defendable.
Now about your technical question:
"Registering with the queue" doesn't mean "putting in the queue" (the garbage collector does it by itself when the object becomes eligible for garbage collection). And when it happens, the MaintenanceThread instance removes the object from the queue (line "while ( (lostConnection = refQueue.poll()) != null) {" in its run() method. Now if you analyze the whole MaintenanceThread.run() method, you'll see that the ReferenceQueue is emptied at least every second.

I think clear from Reference should be exact to use in the unlock method to unregister it.


For sure not. And I guess you now understand why.
Regards,
Phil.
 
Whose rules are you playing by? This tiny ad doesn't respect those rules:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic