Hello Manuel,
if i understand correctly, you have chosen to use objects serialized over socket to implement your networking code (and not the RMI framework). It means you have to code the server entirely, and also how the server will deal with the threads.
First, i found this link that should be useful on this issue :
http://www.cim.mcgill.ca/~franco/OpSys-304-427/lecture-notes/node65.html Secondly, in my opinion, the two approaches you mentioned (one thread per client, one thread per request) have another difference than the ones
explained in the link above, this is about the client identification.
If you use the "one thread per client" approach, it's easy to identify the
client requests in the server code (and also to synchronize on a client
basis), because the thread id is the client id. On the other hand, with
the "one thread per request" approach, you don't have the client identification out-of-the-box (you need to add a token id in the request, at least inside the server process). In that case, the thread often comes
from a thread pool created at server startup.
So, knowing if you need client identification in the server code can help
you to choose between the two approaches.
Hope it helps,
Gilles
PS : i used the RMI framework for my project, and in that case, there is no
choice to make, because this framework use a "one thread per request"
approach (the requests for a given client can be processed by
different threads on the server).
[ November 11, 2008: Message edited by: Gilles Marceau ]