File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Help on Multithreading Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Help on Multithreading" Watch "Help on Multithreading" New topic
Author

Help on Multithreading

Rudy Yeung
Ranch Hand

Joined: Dec 27, 2000
Posts: 183
Grateful if anyone can help me on this. Currently, my client and server program does not support multithreading. However, I am able to start two clients and have them connected to the same server, and then update the server database. If that is the case, why I still need to implement the multithreading then. I mean even without the multithreading, I still manage to get the concurrent access work. Maybe, I guess I have something not clear conceptually, or missing out something.
Aron J. Skantz
Greenhorn

Joined: Oct 12, 2000
Posts: 26
Hi Rudy!
I believe that i saw in some other thread that you are using RMI, and by that you're already supporting multi threading!
The server in RMI is by default (and as concept) multi threaded, accepting connections from more than one connection at a time. You said yourself that you could connect with two clients to the server. The RMI server creates threads for the clients as neccessary and can even reuse old threads for new clients (and in that way making it impossible to ID a client from the thread-ID alone).
Only if you are using sockets directly (and not RMI) you have to activly start threads for each connection, by waiting and listening for clients trying to connect.
I hope that i understod your question correctly.
Regards,
\Aron
Rudy Yeung
Ranch Hand

Joined: Dec 27, 2000
Posts: 183
Yes, that is exactly my question. Originally, I think I still need to create a thread for each client connection using RMI. But now as you said, I do not need it anymore. If I do not need o create a new thread and the RMI itself has already helped me handling the multithreading , how will the lock and unlock method in the data class know which client is requesting a database updating. Or, is there any way I can identify the client using RMI? Even though I adopt the RMI, I still need to make the database updating threadsafe.
Aron J. Skantz
Greenhorn

Joined: Oct 12, 2000
Posts: 26
There has been much debate over this, but there are basically two ways to do it.
The first way is what i'm using and is the "lazy" way i guess. I trust the clients (since i've implmented them myself) to follow the critera to lock->read->modify->unlock when booking which means that no client will try to unlock before locking. This results in that the server doesnt need knowledge of which client that locked a record since only the same client will try to unlock it.
The other way is what you are trying to do, ID the client. As you said you cannot trust the thread-id's so you need another way. I havnt implemented this myself but if i did i would try to generate a unique id for each client and keep a list on the server to assure that no two clients get the same id. Generation of id probably is easiest to do using a function including system time. Then when locking a record, tell the server the id and the same thing when unlocking.
But as i said, i havnt done this myself, so who am i to talk
\Aron
Rudy Yeung
Ranch Hand

Joined: Dec 27, 2000
Posts: 183
Let me pull some other people who may be working on this for their comments.
Adrian Yan
Ranch Hand

Joined: Oct 02, 2000
Posts: 688
Rudy, I don't use client id at all.
But if you do, one of the option is to generate an id using hash. Associate the hash with the record it locked.
Rudy Yeung
Ranch Hand

Joined: Dec 27, 2000
Posts: 183
Adrian,
Basically, you just follow the same approach number 1 as Aron mentions, right?
Rudy
Dilip kumar
Ranch Hand

Joined: Oct 16, 2000
Posts: 360
The java.rmi.server.RemoteServer.getClientHost method returns the client host for the current invocation on the current thread.
source: http://java.sun.com/products/jdk/1.2/docs/guide/rmi/faq.html
Adrian Yan
Ranch Hand

Joined: Oct 02, 2000
Posts: 688
Yes, Rudy.
Dilipkumar: I see you point, but if you think about it. What if the examiner doing the testing is gonna run two GUI clients on his machine and connect to the Server at the same time?
Aron J. Skantz
Greenhorn

Joined: Oct 12, 2000
Posts: 26

Sorry, my mistake. What i meant to say was "can even reuse old threads for new calls", not clients. This means that if the same connection (client) makes a second call before the leasing time for the first thread created expires, then it may be reused. This also means that each call from a client might run in a new thread.

\Aron
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Help on Multithreading