Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Is RMI threadsafe?

 
Daniela Ch
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
http://java.sun.com/j2se/1.4/docs/guide/rmi/spec/rmiTOC.html
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?
Daniela
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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".
Bollocks.
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
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yes
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic