I guys, I have a facade class that have methods like search and book. This object is always instanciated on the server side of the network. The locking is done directly in the book method so the client only have to call the method to book a record and doesn`t have to care of the lock mechanism. My question is, if a client crash while calling the book method, since this method is located on the server side of the netword, can I assume that the method will always complete( so the unlock method will always be called and no record will stay locked when the crash occur ). I haven`t found a clear explanation for this so your help would be appriciated. Joe
Hi Joe If I understand your question correctly, then the answer is that the client crashing in these circumstances will not cause the record to remain locked. I am assuming that your book method looks a bit like this:
Since the networked client is running in a separate virtual machine, any crash will not affect the thread that is executing the book method, so once the instruction to book has made its way safely from the client to the server, the client has no further say in what happens to the record. However, exceptions thrown during execution of the book method on the server could leave the record remaining locked (i.e. during the update or unlock sections). From what I can gather, some people are catering for this eventuality, others not.
"One good thing about music - when it hits, you feel no pain" <P>Bob Marley
Hi Joe, Welcome to JavaRanch, Have you seen the topic "Should lock methods be callable by the client"? Can we count you as a three tier / thin client person? One of the nice things about this assignment is that there is no deadline. So you can take the time to experiment with things that you are unsure about, which will help you to understand the technology better. So for your question, you could write a simple program to test what happens. To give you an example of what I mean, I have included below a program I wrote to test this. My program is actually a little more complex than it needs to be. I deliberately included a Connection Factory and implemented Unreferenced so that I could see when the server knew that the client was no longer connected, and could see what would happen after that. Likewise I used a daemon thread for my client so that it would always behave in a predictable way - I could have just hit Ctrl-C to stop the client and that would also have worked.
Note that this can all be put into one file (ClientDied.java) but you have to run rmic against two classes:
To run it, start the program in one window:
Then start it again in another window, which will run the client portion:
Then see what you get in both windows Do you understand what has happened? Do you understand why this should happen? As always, if anyone has any questions, please ask them. Regards, Andrew
Hello Andrew, As this thread is about RMI so I think this is right place to ask my questions regarding RMI. I have same desgin like Max's book. I tried to print out number of connected clients from my RMI server. As I have seprate Data class instance for each client, so in that contructor I just print out the number of instance created. But when I run client programe with 15 diffrent threads server only print one time "One client connected".I tried to undersatnd through books but didn't get it. Second problem is, when I create 15 client(threads) it works fine but above that I get exception (something like SocketFactory) but program ends proper way. Can you please explain me? Regard's Manoj
author and jackaroo
I have same desgin like Max's book. ... I have seprate Data class instance for each client
Max's book talks about having one instance of DVDDatabaseImpl per connected client in the chapter on threading. However when you get to the chapter on Networking, you will see that the RegDVDDatabase class creates a single instance of DVDDatabaseImpl and registers it as the one instance that all connected clients will use. So if you have followed Max's design, it is quite possible that you only have the one instance of Data class for all your connections. The code that I posted above has two classes which extend UnicastRemoteObject: ConnectionFactoryImpl and MyServerImpl. The ConnectionFactoryImpl class creates an instance of MyServerImpl for each connected client. Do you also have some sort of factory in your server code?
Second problem is, when I create 15 client(threads) it works fine but above that I get exception (something like SocketFactory) but program ends proper way.
Sorry, you would have to provide the real exception for me to work out what is going on here. I suspect that the exception is being thrown from the RMISocketFactory (which is why you saw it in the stack trace). Please cause the exception to occur again, then paste the entire stack trace into a post so we can look at it. Or even better: try typing the name of the exception into the JavaRanch search engine, and see how many times that exception is listed in this forum. Possibly there will only be one or two threads that discuss it, and they will tell you what the problem is. Wild guess: It is possible that you have come across the bug with Sun's RMI Registry which cannot handle large numbers of simultaneous connections. The exact number of clients that can connect simultaneously to Sun's RMI Registry varies depending on your hardware, the operating system you are using, how busy your machine is .... If you put a delay in your code which is getting all the connections (even just a 100 milliseconds between connection attempts) you can normally get much higher numbers of connected clients. Regards, Andrew
Joined: Sep 13, 2003
Hello Andrew, You are right, I am just creating one instance to serve clients. I had impression that I am using one instance per client . Thanks a lot. About exception I searched the forum and come to a conclusion that either my O.S(XP)or RMI has a bug. May be I am wrong. Following is an Exception-: exception.java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused: connect at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:567) at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185 ) at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171) at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:313) at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source) at java.rmi.Naming.lookup(Naming.java:84) at thread.doTest(thread.java:28) at thread.run(thread.java:14) Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) Client 23trying to lock1
Joined: Oct 11, 2003
Thanks Micheal for the information! Andrew, thanks for the exemple. I'll take the time to test it and see what it does. I am still uneasy with Rmi so I guess trying a couple of things with it won't hurt. Joe
author and jackaroo
About exception I searched the forum and come to a conclusion that either my O.S(XP)or RMI has a bug. May be I am wrong.
That does sound like the problem mentioned in this thread. You can fix this by putting a delay between your attempts to connect (as I mentioned earlier), or by going to a commercial RMI Registry :roll: Or you can just ignore the issue - you can get 'x' clients to connect successfully (whether it is 15 or 23), and you cannot be responsible for Sun's reference implementation of the RMI Registry or for your OS limitations. It is worth knowing about this issue though, as in a commercial environment you would probably have to tell your client to use something other than the reference implementation of RMI and definately use something other than Microsoft Windows XP as the OS. Regards, Andrew