wood burning stoves 2.0*
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


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Is RMI threadsafe?" Watch "Is RMI threadsafe?" New topic
Author

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
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

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".
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

Joined: Dec 13, 2002
Posts: 96
yes
 
Consider Paul's rocket mass heater.
 
subject: Is RMI threadsafe?
 
Similar Threads
mutithreaded rmi server
RMI server...is it multi-threaded class??
a client could unlock a record that it has not locked?
HELP: Muilt-Threaded Server
Is RMI Thread Safe?