In Max's book he connects to the Server when the Client is started, and uses this RMI reference for all further method innvocations. Does anyone know the reason for this design ? I see a problem here in that if the Server is stopped, i.e ConnectionFactory unbound/or deleted. The Client will still have a reference to a remote object, even though the server has stopped. Would a temporary connection be more practical, with the Client looking up the Naming Service every time a Remote Innvocation is required ? In this design if the Server was stopped a client could not access the DB.
Hi Tony, There are always tradeoffs. And deciding between them (and documenting them) is a major part of this assignment. If you have a server side book() method, or if your lock method returns a cookie then you can think about disconnecting from the server between calls. Then it just comes down to whether you are concerned about the overhead of making connections / disconnections. Another upside is also that the server will be able to service more simultaneous clients since they will not all be connected simultaneously. But if your lock method does not return a cookie, and you do not have a server side book() method, then you may not even be able to look at this choice. But is this really a problem? If the connection is lost for whatever reason, the next time you go to use the connection you will get an Exception. And this is the perfect oppertunity for your application to attempt to handle the exception itself: it could try several times to get a new connection, and only if all attempts fail would it need to ask the user for direction. Regards, Andrew
Well it could be a problem, if you stop the Server(i.e unbind the Connection Factory, or Even Garbage Collect it on the Server) as the Client still has a reference to a remote object which it can invoke. Tony
By the way Tony, the same thing could happen if the server crashed (therefore it never got a chance to unbind). If a client then tries to connect before the DGC runs, it will get a reference to the defunct server process. Same again: the first time it attempts to do anything with that reference, it will get an exception. Even with your attempting to connect for each remote method, you are still going to get an exception in this case. So you still have to handle the exceptions. It is only a question of whether you treat the exception as a fatal error and exit, or whether you try to be user friendly and try to recover from the exception. In this case, because the server is dead, the exception is not recoverable, so after trying to get a new valid connection 3 times, my application will then inform the user that it has encountered a problem, and take them back to the connection screen (I did FBNS, so I was able to have a connection screen where the user could select local or remote connection and all the related options). But in the case where someone had just pulled the network cable, or the server had been restarted, then my application would automatically try to get a new connection, get it, and continue as if there had never been a problem. Regards, Andrew
Cheers Andy I thought an Exception would be thrown but I don't think it is, As the Registry is still running, and Remote Data Access Object is still there. It's just the connection factory that has gone. So no new connections, but the old ones can still access the server. Which I think is a bug, but you never know how deeply the marker looks into the project. It becomes a problem if you wish to re-start the server using adifferent db. Also I think you can connect temporarally no matter if your lock method returns a Cookie or not as your data adapter should not leave a record locked. Tony [ September 05, 2003: Message edited by: Tony Collins ] [ September 05, 2003: Message edited by: Tony Collins ] [ September 05, 2003: Message edited by: Tony Collins ]
I've read about this kind of thing at the checkout counter. That's where I met this tiny ad: