aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Data Server Design Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Data Server Design" Watch "Data Server Design" New topic
Author

Data Server Design

lev grevnin
Ranch Hand

Joined: Jan 23, 2003
Posts: 35
The assignment states: "......You may implement your threaded server in more than one class if you choose." I dont understand why there should be any threading involved on the server side. My thinking was this:
1) The server starts and makes some class remotely available which will be responsible for manipulating the database (this class will have methods same as Data class and will use the supplied Data class to get its work done.). Let's name this class DataManager.
2) Client A starts up, obtains a reference to remote DataManager and starts working with the database. Any client can now do the same.
So essentially, a single remote DataManager object will be shared among multiple clients which, of course, will need to 'behave' properly (locking the record before using it and unlocking it after).
Am I missing something? Why do we need some threads on the server side?
thanks in advance
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Try to think through how you would implement a socket-based version of the database (you will have to think this through anyway to justify your choice between sockets and RMI). Before long, you will find yourself spawning threads like there is no tomorrow.
If you use RMI, then the RMI framework takes care of all the threading for you, so it's not quite as visible. But it's still there behind the scenes.
You actually discovered one of the reasons why RMI is (in most candidates' opinion) the most convenient way to implement the requirements.
- Peter
lev grevnin
Ranch Hand

Joined: Jan 23, 2003
Posts: 35
Well, i know how the socket-based server implementation is going to work: Simply grab a Socket for every client from the ServerSocket.accept() and pass that socket into a ClientHandler thread which will handle all the requests coming from the client over the socket. But what about RMI? All we have is a "publicly" available remote object (I envision a single object shared between many clients) that any client can access and use for it's purposes (i dont' know if the RMI framework is spawing off any threads during the process or not, but I don't explicitly spawn anything on the server - just make the remote object available for access.). Where is the threading here on the server side?
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
The threading is inside the RMI framework implementation itself. Under the hood, it will open one or more ServerSockets and listen to them in much the same way that your Socket-based server implementation would do. But it's all done for you, you won't have to worry about how exactly it handles threading. The only important thing is that it does, and that you thereby satisfy the requirements.
- Peter
lev grevnin
Ranch Hand

Joined: Jan 23, 2003
Posts: 35
Pretty cool , Peter, Thanks. This is what i thought. By the way, what's the deal with member statuses? Like you're a bartender, i am green horn someone else is a ranch hand, etc. What does this all mean? WHat do i need to do to get one status or another?
thanks
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Easy.
  • You start life as a "greenhorn".
  • Once you've posted more than 30 times so that everyone's got to know you, you'll become a "ranch hand".
  • If over the course of a few months you occasionally manage to say something sensible and, more importantly, provide the bartenders and sherriffs with plenty of free beer and entertainment, you can get invited to moderate a forum or two and become "bartender".
  • Only the select few ever make it to "sherriff". The main prerequisite is a quick finger on the trouble-trigger so you can help trouble-shoot the 'ranch. Knowing Paul Wheaton helps, too.
  • Authors visiting the 'ranch for the book giveaway become "Author".
  • Last but not least, given that the 'ranch is a volunteer organisation and hosting a high-volume site such as this is not cheap, we're always in need of money. Particularly generous donors can pick a custom title, such as blacksmith, bouncer, bounty hunter, brave, butcher, chicken, chicken plucker, cow, cowboy, cowpoke, deputy, drifter, dude, farmer, floozy, gambler, goat, goat herder, goat roper, gold digger, grave digger, gunslinger, hanging judge, hired gun, hog slopper, homesteader, house madam, miner, outlaw, pig, rancher, ranger, rustler, sanitation engineer, scout, slicker, stable boy, stranger, town drunk, ugly texan, varmint, or village idiot.
  • HTH,
    - Peter
    [ January 24, 2003: Message edited by: Peter den Haan ]
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Data Server Design