It used to be that socket allocation was a major resource limitation ... [details omitted] ... RMI solves this problem by reusing sockets. In other words, if a client JVM sets up a socket connection to a server JVM, then the connection is actually kept alive for a short period of time by the RMI infrastructure. If, after the client request has been handled, a second request is made from the same client JVM, that request will reuse the same socket connection. This means that the number of socket connections required by an RMI server is approximately: 1 + number of simultaneous requests.
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
What you were saying is that you are not concerned over the additional system resources and potential code complexity of opening up individual RMI remote objects (otherwise called servers) becuase your are concerned over uniquely identifing clients between lock and unlock? In order to avoid my misreading again, could you verify that this is what you mean?
I think you might benefit from further discussion about RMI thread handling or the thread renaming technique
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
It will give me the powers of the gods. Not bad for a tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|