• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

WeakHashMap Solution How is it flawed ?

 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm using the WeakHashMap solution to avoid problems when clients crash while holding a lock. I can't understand what the problem is with it. Seems good to me.
If the client crashes and it's serverside object is garbage collected, the lock is removed. Where's the problem ? I can see it might take time for the gc to run but is this a problem.
Andrew Phil anyone
Tony
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tony,
Theoretically, when a element is removed from the Map, there is no entity to call notifyAll on it(the Map), Thus, its possible that the other threads that are synchronized on the map won't notice the change. In practice, this has never been a problem, AFIK. However, it is possible.
M
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tony and Max,

Theoretically, when a element is removed from the Map, there is no entity to call notifyAll on it(the Map), Thus, its possible that the other threads that are synchronized on the map won't notice the change. In practice, this has never been a problem, AFIK. However, it is possible.

In practice, this has never been a problem because the probability that it happens is very little. So you may see that issue just as a little flaw or little bug.
The issue happens (by lack of notification) only in this case : when there are lock claimer(s) waiting for the lock owned by the crashed client and there is no other lock granted at the time the client crashes (so no future notifyAll() peformed in unlock()).
Tony, you'll find a suggestion to circumvent that issue (complete code) in this thread. Don't pay too much attention there to my critiques about the WeakHashMap solution. It is 100% valid, but as for all solutions, it's worth while to make it safe.
Best,
Phil.
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cheers Phil and Max
Ohh so the pre-condition of this bug is that there are:-
No Locks
Client 1 locks record x
client 2 waits on record x
client 1 crashes with lock

No clients to notify all on until someone else turns up and waits.

... and if my Auntie had balls she'd be my uncle.

Quite a rare occurance I would think.

Will the JVM automatically notify a thread if it waits to long ?
Tony
[ September 15, 2003: Message edited by: Tony Collins ]
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tony,
Quite a rare occurance I would think.

Yes, and that is why Max wrote "However, it is possible." and I wrote "the probability that it happens is very little". But is the fact that a bug has little chances to manifest itself a good reason to not correct it ?!
Will the JVM automatically notify a thread if it waits to long ?

No, AFAIK.
Best,
Phil.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
/*
Originally posted by Philippe Maquet:
Hi Tony and Max,

In practice, this has never been a problem because the probability that it happens is very little. So you may see that issue just as a little flaw or little bug.
The issue happens (by lack of notification) only in this case : when there are lock claimer(s) waiting for the lock owned by the crashed client and there is no other lock granted at the time the client crashes (so no future notifyAll() peformed in unlock()).
Tony, you'll find a suggestion to circumvent that issue (complete code) in this thread. Don't pay too much attention there to my critiques about the WeakHashMap solution. It is 100% valid, but as for all solutions, it's worth while to make it safe.
Best,
Phil.

Hi Tony,
That solution seems to be a bit more muscular then it needs to be, IMO. If you're really, really concerned about this issue, try adding the following method to the Data method


Then simply call this method from your factory in an endless loop after you start up Server, like
the last line of the following


HTH,
M
[ September 15, 2003: Message edited by: Max Habibi ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic