• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

client server

 
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
From my understanding, the SCJD assignment should be client server oriented. That means that we need to have client and server processes running.
However, the case seems not totally that.
Questions:
a) For local case, we do not need to have server process running. If the client can access the local database without going through socket, there is no interprocess communication. Thus, we just run client is enough. Am I right ?
b) For remote case, this is a real client/server case. We need to have client and server processes running. How do we start the client and sever process ? I think we should give HOST DNS, PORT and DbName to both processes.
Server uses the given parameter to contruct the ConnectionFactory's URL and register with rmiregistry. Client uses the parameters to construct url so that it can do the lookup from URL. Am I right in this case too ?
c) Once the client got the ConnectionFactory from server, it can call its Factory method to get an instance of RemoteDataAccess object. This RemoteDataAccess object is different instance for each client. In order to enable client performing its database query action, we need to cache the instance. However, we do not need to do any manipulation in server because the client can use the RemoteDataAccess client stub to perform the needed operation as log as the real instance exists in server. Upon completion of operation, the client just call close() method. Server will remove the instance from cache. Am I right in all the scenarios ?
d) How about error recovery ?
d.1) The server returns RemoteException.
d.2) The server returns IOException. (failure caused by the construction of RemotedataAccess object)
d.3) The server returns DataException.
d.4) The server downs when the client is performing operation.
d.5) The client downs before calling close().
d.6) The communication down between client/server. What happens after the communication is back ?
d.7) Client downs and comes back ?
Please discuss the each questions. I need to have clear picture about how to do the client/server design for the assignment.

Thanks,
John Chien
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


a) For local case, we do not need to have server process running. If the client can access the local database without going through socket, there is no interprocess communication. Thus, we just run client is enough. Am I right ?


Right, in non-networked mode, there is no server. The client simply opens the local database.


b) For remote case, this is a real client/server case. We need to have client and server processes running. How do we start the client and sever process ? I think we should give HOST DNS, PORT and DbName to both processes.


The cleanest way to start the server and the client is:
java -jar server.jar [port]
java -jar client.jar
When you start the server, you don't need to provide the host dns, because first, the server program knows it already, and second, it's not used by the server. Whether you specify the database name or not during the server start up is a matter of your design. My design decision was not to provide it, -- the server would just open the database upon request from a predetermined location.
Now, regarding the client, you have an option to either switch from local to networked mode on the fly or have a way to start your client in two different ways, -- one for local mode and one for networked mode. If you decide to implement the "on the fly" switching, you can start the client without any parameters, and have a connection dialog where you would ask the user to specify the connection type and the corresponding parameters.


Server uses the given parameter to contruct the ConnectionFactory's URL and register with rmiregistry.


If you are thinking about the connection factory that has been discussed in multiple threads here, then its not the connection factory URL, but the connection factory itself that should be bound to the registry.


Client uses the parameters to construct url so that it can do the lookup from URL. Am I right in this case too ?


Yeah, sort of. The client looks up the registry and gets a connection factory from it.


c) Once the client got the ConnectionFactory from server,


The client gets the connection factory from the registry.


... it can call its Factory method to get an instance of RemoteDataAccess object. This RemoteDataAccess object is different instance for each client.


Good.


In order to enable client performing its database query action, we need to cache the instance.


Not sure what exactly you mean here. The client keeps the instance of RemoteDataAccess for the duration of the client, yes. Is that what you refering to?


However, we do not need to do any manipulation in server because the client can use the RemoteDataAccess client stub to perform the needed operation as log as the real instance exists in server.


Well, the instance of RemoteDataAccess is the real instance of the server object.


Upon completion of operation, the client just call close() method. Server will remove the instance from cache. Am I right in all the scenarios ?


The close() method of the Data? It doesn't remove the instance, it just closes the database.


d) How about error recovery ?
d.1) The server returns RemoteException.
d.2) The server returns IOException. (failure caused by the construction of RemotedataAccess object)
d.3) The server returns DataException.
d.4) The server downs when the client is performing operation.
d.5) The client downs before calling close().
d.6) The communication down between client/server. What happens after the communication is back ?
d.7) Client downs and comes back ?


Catch these exceptions, map them into meaningful text messages and display them to the user.
Eugene.
 
John Chien
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eugene:
Thank you for the reply.
I still have some questions:
a)
According to your answer, the best way is not to provide HOST DNS, PORT, and Database name.
About Database name, I think I can understand. It is really not necessary to give database name because the system itself should know that.
About host dns, and port, I am not quite sure. From what I understood from RMI, there is really no need to have host and port. Becasue the ConnectionFactory will be registered in rmiregistry using a name. The client is going to find it using that name too.
However, I saw a lot of discussion realted to DataAccess, RemoteDataAccess design. They all mention the use of host and port. If we are doing Socket implementation, they are absolutely necessay. How about RMI ?
2. Which machine should the rmiregistry resided ?
Is that the server machine ? If that is the case,
how can client find the rmiregistry to query it ?
3. Are you saying that we do not need to have the disaster recovery mechanism besides handling the exception ?
Thanks,
John Chien
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic