aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes data server Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "data server" Watch "data server" New topic
Author

data server

Prakash Krishnamurthy
Ranch Hand

Joined: Oct 08, 2002
Posts: 154
Hi all,
I have a couple of questions. The instructions say this, "You must create a data server that will accept multiple concurrent network connections and allow them to interrogate and manipulate the database". I am not very clear on what to do for this.
I am using RMI and was wondering if there was a need to create any class that would accept multiple concurrent connections. Doesn't the RMI engine create multiple connections and manage them?
My present server-side design is
interface RemoteRequest extends Remote
public class Request extends UnicastRemoteObject implements RemoteRequest
public class LockManager
public class ReadWriteLock
Public class Data
I am missing something here from a design perspective?
Kindly comment.
Prakash
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11508
    
  95

Hi Prakash,
Doesn't the RMI engine create multiple connections and manage them?

Yes, RMI will handle the creating of multiple threads which will allow multiple simulataneous connections for you.
I think your confussion is because having chosen RMI as your network methodology you no longer see the sense in the requirement "You must create a data server that will accept multiple concurrent network connections".
However if you go back to your original instructions, you had a choice in network methodologies. You could have chosen Sockets instead, in which case you would have had to explicitly handle creating threads yourself so that you did not block each time you accepted a call.
Does the requirement make sense if you consider the alternative network methodology?
The requirement also means that you also have to make sure that your server code is thread safe. In this case, RMI could be a trap if you are unaware that it is creating threads in the background. Put your locking code in a non thread safe class, and you will be in big trouble.
Your design looks fairly standard at a quick glance.
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Prakash Krishnamurthy
Ranch Hand

Joined: Oct 08, 2002
Posts: 154
Great! I saw a few posts out here about a serverConnectionFactory class and did not understand the reason for it.
Thanks,
Prakash
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11508
    
  95

Hi Prakesh,
I saw a few posts out here about a serverConnectionFactory class and did not understand the reason for it.

Your GUI client should be able to connect to the DB in either local mode or in networked mode.
You could handle this by having a series of "if ... else" statements everywhere that you do database lookups.
A better way of doing it is to have a "Factory" class. In your GUI, you create your connection using the Factory class, and do all your database calls through the connection object that you get returned.
This means that your GUI application does not need to know how it is connected - it will always be using the same methods.
If done correctly, it makes your application far more extensible:
  • New connectivity paradigms could be added to the factory without any of your code changing. E.g. at the moment you have "local connection" and "RMI". At some later point you could add "Socket", or "WebServices".
  • In a real life application (not required for FPNS), your user could change which form of connectivity is being used, even if you did not provide them with that conectivity. For an example of this, consider the DriverManager class in java.sql - as long as the the Driver interface is implemented, anybody can create an ODBC driver without Sun's knowledge, and any user can use it in their ODBC compliant program, often without the programmer being aware of the existance of the ODBC database.


  • For more information on Factory design patterns, you could look at Sun's guide to Factorys, however I dont think it is very clear. In my opinion, Gopalan Suresh Raj's guide is better, and has examples in Java and C++.
    Regards, Andrew
    Prakash Krishnamurthy
    Ranch Hand

    Joined: Oct 08, 2002
    Posts: 154
    A better way of doing it is to have a "Factory" class. In your GUI, you create your connection using the Factory class, and do all your database calls through the connection object that you get returned.

    I do have a Factory class in my gui. This has a method "getConnectionType()" which checks for local or remote and then returns a object of that type.
    But from what I understood from the posts out here, I thought there is a need for another one on the server too. If that's true I did not understand why.
    Have I understood it right?
    Regards,
    Prakash
    Claudio Luz
    Greenhorn

    Joined: Feb 13, 2003
    Posts: 27
    Folks,
    To shutdown the data server is sufficient
    to use the keys CTRL-C for shutdown it?
    For example, when the server is startup a message is prompted to the user saying following:
    " Server startup.. CTRL-C to shutdown"
    is this an approach valid?
    Is it valid to differents operating system?
    ( unix, solaris , etc.. )
    Comments, please.

    Claudio Luz
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11508
        
      95

    Hi Prakash,
    I agree with you - having a factory is good on the client side, but I dont believe it is necessary on the server side.
    Regards, Andrew
    [ April 12, 2003: Message edited by: Andrew Monkhouse ]
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11508
        
      95

    Hi Claudio,
    Please dont change topics midway through a post. You really should start up a new topic.
    If you want to start a new topic for this, I will copy this post into the new topic.
    But to answer your question, using a ctrl-c to stop the server is possible, at least under Unix and Microsof based systems. From memory it is also workable under VAX VMS.
    However you would have to think about whether it is desirable or not. If you just kill the server while it is in the middle of a write to the database, what happens to your data? What happens to the clients?
    One alternative would be to have a GUI server (this may be a requirement in the new assignments). Then you could have a method of instructing the server to shutdown that allows it to do so cleanly.
    Another alternative is to have the server read commands from the terminal / send status messages to the terminal. Again, entering a command of "quit" would allow for a clean shutdown.
    More alternatives (although probably way out of scope): have an RMI method for shutdown (so either the standard GUI or another application can initiate a shutdown - probably need some security for this). or have the server listen on a particular port for administration commands.
    I am sure that other ways of having a shutdown could also be thought of.
    Regards, Andrew
    Claudio Luz
    Greenhorn

    Joined: Feb 13, 2003
    Posts: 27
    Thanks for yours comments, Andrew.
    I have thought that shutdown the server to CTR-C is not against the requiriments because this is not will put the database in non-secury way. If the server is shutdown and the client imediately right booking the seats we could have 2 cases:
    1. The numbers of seats was decrease by 1, before the shutdown process or
    2. The numbers of seats continue the same.
    Remember, that the client before "lock" that record, therefore that client is unique owner of record.
    Of this way, on the worst of cases the client has not had its booking finished .. and he can always try again
    NOTE: Well, I put this question in this topic because the one is about "data server" then i thought that "shutdown" is matter has relation to that one.
    Sinceraly,
    Claudio Luz
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11508
        
      95

    Hi Claudio,
    The problem I have with shutting the server down is that the data in the data file is now in an unknown state.
    You are assuming two things here:
    1) The OS will make sure that the file is still valid, and whatever write operations were in progress will be completed by the OS after the application has died.
    2) Each booking is standalone.
    While point 1 is probably valid for most modern operating systems, I would not like to guarantee it. Worst case scenario, consider a fictitions OS that writes data in nibbles, and stops writing if the application dies. If we were decreasing number of seats available from 16 to 15, and only one nibble got updated, the number of seats available the next time the data file was opened would be either 31 or 0 depending on whether the data is on a big endian or little endian machine.
    OK - so this is a bit outlandish, but to make it a bit more realistic, how about if the database requirements change in the future so that a checksum is calculated after each write, and the file is then updated? In your case, the data has been written, but the checksum will not have been calculated - next time the file is opened, the file will fail the checksum, and the file will be declared invalid.
    In the same manner, if the file is not closed properly by the application, and the OS decides to truncate the file at the point it was writing, then your file could be corrupt.
    My other problem is with the idea of atomic updates. I think this is acceptable under the current assignment rules, but it is not safe for future enhancements. One likely scenario would be that people would like to book return flights (this is the most common type of booking in the airline industry at the moment). In this case, the outgoing flight would be booked, but the return flight would not be booked, and the user would only know that the database has died (you are telling them that aren't you?) and not know whether either booking succeeded or not.
    ---
    OK - I know I have gone well outside of scope, but bottom line is that killing an application without giving it a chance to clean up is (IMHO) a really bad idea.
    I dont even allow the "CLOSE_ON_EXIT" in my GUI - I always change this to a DISPOSE_ON_EXIT so I can catch it and perform an orderly shutdown.
    Just my opinion - as you feel you can justify your decision, then you can ignore it. Just make sure you do document it for the examiner though.
    Regards, Andrew
    Claudio Luz
    Greenhorn

    Joined: Feb 13, 2003
    Posts: 27
    Thanks again for worth comments, Andrew.
    Well, I think that the requeriments of assignement not clarify if it necessary atack cases where the client or same the server is "crashed" or same to made a server which will be the proof of bullets.
    Also, i am trying avoid implement a gui or some like-gui console to the server because i dont know if the "terminal" where the server will be running has some "graphic" interface appropriate
    In a first moment, i had implemented a gui to the server, but after thought a lot , i decides that a gui or console was a "plus" not necessary. Maybe, i could to implement a application which could be executed in other session using the line command,on the side server, by administrator to shutdown the server in a secure manner.
    Anyway, thanks again for your suggestions.
    Claudio Luz
    S. Ganapathy
    Ranch Hand

    Joined: Mar 26, 2003
    Posts: 194
    Hi Prakash,
    What does LockManager and ReadWriteLock classes does in your design? Do you have lock/unlock methods in your DB interface?
    Please let me know. I am confused to understand your design. As in other topics, they are implementing lock/unlock functionality. Here in your case, I found the two classes I mentioned.
    Thanks in advance
    GVRao
    Prakash Krishnamurthy
    Ranch Hand

    Joined: Oct 08, 2002
    Posts: 154
    Venkateshwara:
    Hi Prakash,
    What does LockManager and ReadWriteLock classes does in your design?


    Do you have lock/unlock methods in your DB interface?

    Which DB interface are you talking about? I assume you are talking about the one which extends Remote. Yes, I do have lock/unlock mehtods in that interface.
    Kruger Scheitz
    Ranch Hand

    Joined: Jul 31, 2002
    Posts: 72
    and how do you do a clean shutdown on the server? Do you consider calling the unbind() method as way to shutdown the server?
    please reply asap
    Prakash Krishnamurthy
    Ranch Hand

    Joined: Oct 08, 2002
    Posts: 154
    and how do you do a clean shutdown on the server? Do you consider calling the unbind() method as way to shutdown the server?

    I did not use the unbind method. Infact, I did not have any way of "smoothly shutting down" the server. I did not do it because I did not see it defined in the "requirements".
    Hope I answered your question. Let me know if I didn't
    PK
    Jim Yingst
    Wanderer
    Sheriff

    Joined: Jan 30, 2000
    Posts: 18671
    I added a server shutdown method which (a) does unbind() and (b) ensures that the Data class's FileChannel is closed promptly. It's true that this isn't required by the assignment, but it's useful for unit testing if you want to run a number of different tests, and some of those tests need to start from a fresh server instance. The shutdown() method makes it easier to kill an old server and start a new one.


    "I'm not back." - Bill Harding, Twister
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11508
        
      95

    Hi Kruger,
    I did an unbind, and I locked the entire database before I allowed the shutdown. I made sure that the Data's close() method was called before final exit, to ensure that all data was written and the file was actually closed (overkill, since that was already handled in a finalize() method, but then I usually go overboard in meeting requirements ). Informational messages were sent to the terminal to let the user know that shutdown was progressing, and that it was waiting for the lock to be granted, so that they could kill the process if they really needed to.
    Regards, Andrew
     
    wood burning stoves
     
    subject: data server