Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

WeakHashMap and single server thread

 
John Cogan
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have implemented the WeakHashMap solution and have built locking around this. I sychronized on the WeakHashMap called lockedRecords.
I also have a one instance of the Data class per client.
However, the server only has one thread, it doesn't spawn threads per client.
My question is, can the locking be valid if there is only one thread?
 
Liang Anmian
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are using RMI, threading is handled for you automatically. If sockets, by right there should be one thread running per client.

Maybe a more experienced one can help out?
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11943
212
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi John,

I think we will need an answer to Liang's question before going too much further with your question.

If you are using RMI, then RMI itself will allocate threads from a pool, and you have no control over which thread will be used for any remote call. Hence the need for an instance of the Data class per client that can then act as the key in your WeakHashMap.

If you are developing a Sockets solution, you should create new threads yourself for each connected client. Since you are controlling the creation of threads yourself, you have the choice of using either the thread or the instance of the Data class as the key in your WeakHashMap (actually, since you can use the thread as the key, you don't really need multiple instances of the Data class).

One more thing for you to think about: just having a WeakHashMap does not solve the orphaned client issue completely. There is the potential that client 'A' locks record 5, client 'B' attempts to lock record 5 and goes into wait state, then client 'A' crashes. In this case, after a certain amount of time the lock indicator will be removed from the WeakHashMap, but client 'B' will not be notified. There is a simple solution, but I will let you think about it for a bit first ...

Regards, Andrew
 
John Cogan
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
Thanks for that explanation.
Unfortunately, I'm using the debugging in Eclipse and only one thread shows up in the server no matter how many clients. So this is misleading.

I am aware of this limitation with the disconnected cliend but because of the exam notes...

"The requirements for this assignment don�t require you deal with client crashes, or other abnormal termination issues. That is, they don�t require that you deal with timeout of locks."

...I wasn't too worried about it.
I thought perhaps a finally block but this would not surfice. Or even to check for changes in the size of the WeakHashMap.
A simple solution continues to evade me.
Best regards,
John
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11943
212
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi John
Or even to check for changes in the size of the WeakHashMap.
A simple solution continues to evade me.


Nearly there. It is not just a change in the size of the WeakHashMap that is important - it is the size of the WeakHashMap contrasted with what your program believes should be the size of the WeakHashMap.

Now if you put that code in a daemon thread ...

Regards, Andrew
 
Ian Wark
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,

Just on this topic I am having a related but different problem. What happens if my client is blocking indefinitely on IO? I can take its lock away, but I want to interrupt it. Since I am using RMI I do not know how to identify this thread, however.

I have thought about the Unreferenced and WeakHashMap idea, but from what I understand it takes a long time before unreferenced resources get cleaned up. Waiting for 5 or 10 minutes seems too long for even the most patient GUI user. I read that you could change a parameter when starting up the RMI server to reduce the default period, but I do not believe that I am allowed to specify that parameter. In my specs it doesn't seem to allow it.

So I have a daemon thread that (ideally) will interrupt a thread whose lease on a lock has run out (leasing functionity is OK), and then remove the lock from my locked items collection. At the moment it only does the latter, however. By the way, I was able to use NIO for my IO (I checked with Sun Japan), so it is possible to interrupt a blocking thread.

I am passing in uids to my LockManager so that I know that it is the same client, but I can't use a uid to track down a thread the other way. [Or can I? :roll: ]I am using a fat client, because of the requirement to make available all public methods in Data.java to the client.

I have run out of steam on this one. Not sure what I can do here. Any help greatly appreciated.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ian,

I think you're working too hard here(and in the IO/Thread interrupt question). I applaud your efforts and ingenuity, but you don't really need any of this to pass the exam: it's just cool.

My opinion is that you should focus on getting a no-frills implementation of the project done, get your cert, frame it, go get a beer, and then see if you want to add functionality to it.

Good luck!
M
[ April 29, 2005: Message edited by: Max Habibi ]
 
Ian Wark
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK Max,

Roger that.

One of the main reasons I am trying so hard, is because you
pointed out the issue of blocking IO in your book.

So tantalisingly close...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic