File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Is RMI threadsafe? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Is RMI threadsafe?" Watch "Is RMI threadsafe?" New topic

Is RMI threadsafe?

Daniela Ch
Ranch Hand

Joined: Dec 13, 2002
Posts: 96
I was thinking yes until I saw this on the web :
"RMI is not threadsafe, i.e. when working with threads you still need to take care of synchronization yourself. (for more see RMI specification
3.2 Thread Usage in Remote Method Invocations)"
here is what the link refers to :
"3.2 Thread Usage in Remote Method Invocations
A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Since remote method invocation on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is thread-safe."
is it or no?
Peter den Haan
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
I dislike the expression "X is threadsafe". It leads to piles of confusion.
An statement that comes up often in this and other forums is "it's better/easier to use a Hashtable than a HashMap, because a Hashtable is threadsafe".
Yes, Hashtable is threadsafe in the sense that its methods are synchronized so that you won't wreck the data structure when you access it using multiple threads. That does not mean that any code you write using the Hashtable is threadsafe. In fact I have argued many times here and elsewhere that it is actually more likely to be threadunsafe because the so-called thread safety of Hashtable lures you into a false sense of security. It doesn't help you. For 90% of the problems, the synchronization of a Hashtable is in entirely the wrong place, at entirely the wrong granularity, because the operations that need to be atomic with respect to other threads are much coarser grained than the little Hashtable methods.
The boys from Sun recognised this, of course, and introduced the mercifully unsynchronized Collections framework in JDK 1.2. In the rare cases that a synchronized Collection is called for, you can use the Collections.synchronizedFooBar() wrapper classes.
Back to RMI.
RMI is threadsafe in the sense that Hashtable is threadsafe: accessing RMI using multiple threads, or from multiple JVMs, won't wreck it. It fully supports this mode of operation. That does not mean however that your remote objects are threadsafe. You will have to take care of that yourself; with very few exceptions, you would do that in exactly the same way as you would ensure the thread safety of local, non-RMI objects. For the purpose of the assignment, the exceptions aren't important (they have to do with callbacks and all that jazz).
Other than Hashtable, however, RMI itself must be threadsafe as well in order for it to be useful, so don't take this as a plea for an unsynchronized RMI implementation
Does that clarify things?
- Peter
[ January 06, 2003: Message edited by: Peter den Haan ]
Daniela Ch
Ranch Hand

Joined: Dec 13, 2002
Posts: 96
I agree. Here's the link:
subject: Is RMI threadsafe?
It's not a secret anymore!