How simple can a Server be?

[Martin Habicht]

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]

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]

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 den Haan]

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