I have a servlet that is doing an RMI call to a single remote object. Since any invocation of the servlet is created in a new thread, I'm observing a new TCP/IP connection for every single servlet request.

Sameer Tyagi

A method dispatched by the RMI runtime to a remote object implementation (a server) may or may not execute in a separate thread. Some calls originating from the same client virtual machine will execute in the same thread; some will execute in different threads. Calls originating from different client virtual machines will execute in different threads. Other than this last case of different client virtual machines, the RMI runtime makes no guarantees with respect to mapping remote object invocations to threads.
Consider the following example.

A remote object MyObject is bound to the registry and it has a method called mymethod().

Servlets obtain a reference and invoke this method in their service methods. Let us assume that 500 concurrent calls are made to this method from the servlet instance. Does this mean that the 500 calls will be queued up ?

Well, actually no. The RMI object can be called by several threads concurrently. It is very easy to test: simply have a counter in the object which is ticked up one at the beginning of the method, and decrease it at the end. This way you'll know how many threads are working on it concurrently. Print it out and you'll know for sure what's happening.

It is rather simple: RMI/JRMP maintains connections from the client to the server. If a call is to be made and all connections is currently in use another one is created. This will only hold to a certain point however since there is a finite number of server threads.

In the scenario you describe, it would be simple to obtain a reference to the object in the init of the servlet and invoke methods on the objects in the service method. Since you will always deal with the same instance of the remote object at all points in time.

As long as the object itself is thread safe, everything should be fine.