Thanks for reading my post. I need some definitive answer or I�m going to get my eyes crossed in this matter
I have a RMI bound service which will be used by multiple clients simultaneously via RMI calls. How do I serve all the clients in parallel? Do I have to bind new instances of my server object multiple times in multiple names to achieve true parallelism or does the RMI Registry do this for me, by creating a copy of my object and running it in a separate thread for each remote client.
I was able to find this nice little explanation in the RMI Spec.
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.
Though I can read all the words in it, I feel the meaning is in 500 BC Greek. [ February 08, 2007: Message edited by: Isuru Sampath ]
No Winds No Waves
Joined: Jun 26, 2003
I ran a profiler on my application and found that 1 thread is created for every client request. Tried with several client configurations; each time the number of clients were equal to the number of new threads spawned. Also the thread spawning time is analogous to the client request initiation time.
So, what�s with the definition? [ February 08, 2007: Message edited by: Isuru Sampath ]
It says that there might be just one thread serving all client requests, or there may be one thread for every client, or there may be just three threads that handle clients in a round-robin fashion, or anything else: no guarantees are made.
Then it says that, because of this, your server object must be thread safe, meaning that it must work OK if it is invoked from multiple threads at the same time. The easiest way to ensure thread safety is for the server object not to use any shared mutable data -- no instance or static variables whose values can be changed. Otherwise, you have to use explicit synchonrization to protect that shared data.