Server approach - I think I might be missing something

[Ed Villamizar]

Hi Javaranchers,

I am almost done with my assignment but after reading some posts I decided to ask a question about a part of my solution that doesn't seem to be in line with what others have done.

I have URLyBird (1.1.3) and my area of concern is how the server is handling client connections. I have a single instance of Data in both the server and alone modes. I have another class that I called "ClientConnection" which is in charge of handling client (remote) requests and interfacing with the only instance of Data to fulfill them. (My server only provides the following services to clients: find records based on criteria, obtain the database scheme and book a record - I think it is called thin client here).

Now my concern. I have only one instance of "ClientConnection" and a reference to this object is passed to every client requesting it. The client can then use this reference to make booking or searching requests to the server. Most people here seems to have implemented a thread per client and they even keep track of connected clients.

I have done some light testing and having only one "ClientConnection" instance at the server doesn't seem to be a problem. Two clients can obtain the reference to this instance and send requests to the server. I know that for a more scalable server multiple threads would be probably the way to go but isn't my approach acceptable for a small number of clients?

In fact I do not use multiple threads whatsoever in my design. I used them only for testing but there are no multiple threads in any of the official modes, clien, standalone or server. Should I have used them somewhere?

I am planning on performing stress testing on the server by automatically generating multiple client requests in multiple machines and I might end up uncovering issues then.

Is there a limit on the number of times the reference to my only instance of the 'ClientConnection' object can be passed to clients?

Thanks a lot for your thoughts, comments and questions,

Ed

[Andy Zhu]

I am not quite sure understanding your question. I guess different clients act as different "threads" throw networking. If you use socket, you may have to programming threading explicitly. However, if you use RMI, I don't think you need to. There should be some way to queue clients in RMI, if you prefer to.

[Frans Janssen]

Hi Ed,

If you have the URLybird, you probably have the lock method that returns a cookie. Then you don't need multiple Data obejcts or Connection objects to dientify clients, as long as every call to lock() will return a unique cookie.

You probably will have multiple threads that can access said objects imultaneously, so they will need to be thread safe.

Frans.

[Ed Villamizar]

Originally posted by Frans Janssen:
Hi Ed,

If you have the URLybird, you probably have the lock method that returns a cookie. Then you don't need multiple Data obejcts or Connection objects to dientify clients, as long as every call to lock() will return a unique cookie.

You probably will have multiple threads that can access said objects imultaneously, so they will need to be thread safe.

Frans.

Thanks for your comments. Yes, my lock method signature returns a cookie and as far as the same cookie is used for update or delete my Data instance doesn't care where the request is coming from. I have a LockManager that handles locking and all file access are synchronized on the RandomAccessFile used reach the physical file.

[Andrew Monkhouse]

Hi Frans,

If you have the URLybird, you probably have the lock method that returns a cookie. Then you don't need multiple Data obejcts or Connection objects to dientify clients, as long as every call to lock() will return a unique cookie.

Just FYI, the simple fact of having URLyBird does not guarantee that you have cookies. Similarly having Bodgitt & Scarper does not guarantee that you won't have cookies. It is the different versions of either assignment that determines this. Take a look at the question "How may assignments are there?" in the JavaRanch SCJD FAQ for more information.

Regards, Andrew
[ March 08, 2005: Message edited by: Andrew Monkhouse ]

[Frans Janssen]

Hi Andrew,

Thanks for the tip! I thought I had spotted a trend, but apparently it was just coincidence.

Frans.