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
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 ]
posted 17 years ago
It means our mission is in jeapordy! Quick, read this tiny ad!