wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes How simple can a Server be? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "How simple can a Server be?" Watch "How simple can a Server be?" New topic
Author

How simple can a Server be?

Martin Habicht
Greenhorn

Joined: Nov 07, 2001
Posts: 17
Hi
How simple can a Server be, as it gives up to 53 points?
I'm asking because so far I have a very simple Server and all he does is to create an instance of a RemoteData object (which extends UnicastRemoteObject and redirects every mehtod call to a single Data instance). Then it puts it on the RMI-registry. Done! Only one command line parameter: the file name. No GUI, no extras.
Do you think such a server would be sufficient?

I agree, that for a nicer design, I would rather put a ConnectionFactory on the RMI-Registry, which would give each client it's own instance of a RemoteData (Data would still be Singleton). This would also allow tracking of Client-ID's for lock() and unlock().

Do I need to make the Server multithreaded explicitely?
Does the Server needs to have multiple threads to be able to accept a new rmi call before a previous hasn't returned because it got blocked?

After writing this, I guess it have to!
So then I could eighter have a thread for each client or better just start a new thread each time a request comes in.

any thoughts?!? thanks in advance...
-Martin

kerry shih
Greenhorn

Joined: Nov 04, 2001
Posts: 15
Couple of comments:
Remember that for local usage, you have to completely bypass RMI. UnicastRemoteObject's immediately export upon construction.
I think the general idea is to have only 1 Data instance. If you serve one to every client then your are initializing the whole service on each request. Plus it precludes you from having a centralized management for record locking, id tracking etc.
RemoteObjects and decendants of remote objects are threaded servers once exported. In other words the threading work is done for you. To try it, simply export a server and have multiple remote clients connect.
Hope this helps,
Kerry
Peter Crowley
Greenhorn

Joined: Nov 06, 2001
Posts: 14
Originally posted by Martin Habicht:
How simple can a Server be, as it gives up to 53 points?

You just have to meet the requirements.
I'm asking because so far I have a very simple Server and all he does is to create an instance of a RemoteData object (which extends UnicastRemoteObject and redirects every mehtod call to a single Data instance). Then it puts it on the RMI-registry. Done! Only one command line parameter: the file name. No GUI, no extras.


I agree, that for a nicer design, I would rather put a ConnectionFactory on the RMI-Registry, which would give each client it's own instance of a RemoteData (Data would still be Singleton). This would also allow tracking of Client-ID's for lock() and unlock().

Yes, you need to explicitly worry about threading.

Each time client that connects to your server they will be given a thread to work on. (Multiple clients = multiple threads) And each time the client calls a method, they might be given a different thread. (thread != clientID) For the factory's connections this is not a problem because a client will only be given one thread at a time as long as your client is single threaded, which almost never happens with GUIs. Someone can help verify this, but one of two things happen:
1)Every time a java.awt.event.Event happens your client spawns a seperate thread to handle that event.
2) For every event, the "swing" thread (the thread responsible for doing screen refreshes) handles the event. (I can see problems with this thread being blocked while waiting on the server if this is the case.)
If your client spawns two threads on the client (example #1 above), both could call methods on your server and get two threads running on your server on the same connection object.
Connection factory or not, I say that you should worry about threading.


Please comment if you know for certain that the awt events happen on their own thread for each event or if they share a single thread.


-Peter Crowley


-Peter Crowley,<BR>who is looking for work in North Florida
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Both AWT and Swing are strictly single-threaded, and 99% of both is thread-unsafe. For that reason it is customary to handle time-consuming tasks (such as booking a seat ) in a separate (worker) thread - keeps the GUI responsive.
- Peter
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How simple can a Server be?