Yes, i believe we can state that by using RMI, we are infact using the singleton pattern for the server. The only concern that i have is that if we were to start more than one instance of the server application, then we might have to activly implement singleton. This should however not be an issue since i think it's out of the scope of this assignment. [If a second server (in the same JVM and on the _same_ port) is started an exception is thrown in rebind, preventing any attempt to run double instances. But running server on different ports works. But as i said; i dont think that is a real issue here?]
Regards \Aron [This message has been edited by Aron J. Skantz (edited March 16, 2001).]
Originally posted by Aron J. Skantz: If a second server (in the same JVM and on the _same_ port) is started an exception is thrown in rebind, preventing any attempt to run double instances. But running server on different ports works.
Aron I am confused? Can you explain further:- You appear to be saying that the second server can be "started", and exception will be thrown only in rebind. Can 2 servers "start" in the same JVM in the SAME port?? Or even can 2 servers start in different JVMs but in the SAME port?? As I understand an RMI server gets "started" when 1. if it subclasses UnicastRemoteObject, at the time it is instantiated and 2. if it does not subclass UnicastRemoteObject, then when it is instantiated and UnicastRemoteObject.exportObject() is called. As I understand the RMIServer (I am not talking of RMIRegistry) will be started on an anonymous available port, but since Java2 we can stipulate the port also. As I understand when it get so "started" the RMI Server will internally open a ServerSocket to listen on the port (anonymous or stipulated). But I assumed that some exception should be thrown as soon as we try to start another RMI server instance on the SAME port eg by doing exportObject(object1, 5000); and then exportObject(object2, 5000) where object1 and object2 are 2 RMI server instances. Because I though that only one server could listen on one port. Are you saying that 2 server application can listen on the same port, simultaneously?? Or are you only talking about the port on which the rmiregistry is running? Because the port of rmiregistry is different from the port of the RMI server.
Correct me if I am wrong but - What I understand is that the question of 2 RMI Server instances starting on the same port will never arise. Secondly if 2 RMI Server instances (running on different ports p1 and p2) try to register on the SAME rmiregistry (running on some port p3) with the SAME name then a exception would occur in rebind. But I think the 2 instances CAN register under different names with the same rmiregistry. Thirdly if there are multiple rmiregistry running on different ports (in different JVM's)then the 2 server instances can bind themselves to different registries even under the same name eg. RMI server running on port p1 can bind itself to RMIRegistry running on port p3 and RMI server running on port p2 can bind itself to another RMIRegistry running on port p4. Fourthly I think even a single RMI Server instance running on port p1 can bind itself to multiple registries like RMIRegistry on port p3, and RMIRegistry on port p4 under same or different names. If the above is correct (or some parts are) then it may not be right to say that singleton pattern is inbuilt into RMI or that merely by adopting RMI we are adopting the singleton pattern. I will be grateful if you can remove my confusion.
[This message has been edited by Rahul Rathore (edited March 17, 2001).]
Aron J. Skantz
posted 19 years ago
Rahul, First of all, sorry for making such a bad statement leading to this confusion. No, two RMI servers cannot run on the same port, neither can two RMI registries listen on the same port for connections. What can occur, that can be an issue when discussing if RMI is singleton or not, are 1: Using one RMI Registry and binding two instances of our RMI server in different names (and different ports as supplied by not specifying our own in unicast constructor or exportObject) 2: Using two RMI Registries running on different ports and binding two instances of our RMI server, one to each. By this i agree with what you said and apologize once again for bad use of the word "server". My conclusion is that we cannot simply say "I use RMI and by that singleton". We must state under what conditions a RMI server acts as if singleton where implemented for a multithreaded environment, and explain why the above cases isnt an issue in this assingment (or indeed, if they are). This is how i see it but I am in no way an expert on RMI. Thank you for bringing this up Rahul and hopefully we both learned something from having to think this through, I did anyway. \Aron
[This message has been edited by Aron J. Skantz (edited March 17, 2001).]
I will suppress my every urge. But not this shameless plug: