Originally posted by lev grevnin:
1. Why should I worry about how RMI executes remote invocations (in separate thread each method or in the same thread)?
Some try to derive object identity or client identity from the identity of the thread that is executing your code. Max Habibi, who published a book on the subject, is one of them. I believe this to be a mistake, even though (the way Max does it) it happens to work with the current implementation of RMI.
2. Why is it important for me to realize that RMI doesn't gurantee mapping between remote invocations and threads?
It removes any temptation to try to use Thread.currentThread() for the purpose of identifying clients.
3. Forgetting how RMI processes method invocations, can i just assume it's analogous to ordinary handler thread-per-client type of deal? (just like with Sockets, where each socket upon client's connection to the server is passed into a newly spawned thread on a server side for further processing) I mean, as far as thread safety goes.
As far as thread safety goes, yes: making your stuff threadsafe for RMI is no different from making it threadsafe in any other multi-threaded situation. You're not missing anything.
In fact, you just gave a nice illustration of the issue at hand; in your hypothetical Socket implementation, the next time that the same client invokes the same object, you are likely to get a completely different Thread. In my exegesis of the passage you quoted, this is potentially true of RMI as well. No guarantees. Whatsoever.
- Peter