UrlyBird - RMI server and Data design issues

[Thirumurugan Mylrajan]

Hi All,

I have nearly completed my assignment, but was stuck with this issue.

RMI give no assurance about thread and the server has to be made thread safe. Now what is the criteria for thread-safe?.

I could,

1. Use one data class and let the threads use the individual methods of the data class. There are no modifyable instance variables within the method. The client directly calls the Data methods through paramaters. The data classes access the physical file through a singleton filehandler instance.

2. Use separate data classes for each data "Call". I am doing this right now, but I feel its a over kill creating so many classes.

3. Create one data class per client. I will have to redesign my intefaces and I prefer this the least.

My lockManager is a singleton and works whether there is multiple or single data class instances. I myself put a stone in my foot by using a MDI client, which can have multiple search windows within it. But theoritically it should not create problems.

I read in Andrew's book that he prefers separate data classes to prevent thread safety issues, but what are the issues?. I prefer point (1), but are there any pitfalls in that approach, am I missing something?.

Thanks.

[John McBird]

I'm doing ver 1.1.1 and using the first design ( a single Data instance
shared by all clients) I see no issues in this design.

[Mihai Radulescu]

Hi, Thirumurugan

If you use only one Data instance you must be also able to make a difference between users, otherwise user A lock record 1 then user B can release it and this can lead to a lot problems.

I think that a Data instance for each client is a pretty solution.

An other point is the singeton(s), they are nice but they only live once.
Think about.

Regards M.
[ July 06, 2006: Message edited by: Mihai Radulescu ]

[Thirumurugan Mylrajan]

Thanks John and Mihai.

Originally posted by Mihai Radulescu:
[QB]Hi, Thirumurugan

If you use only one Data instance you must be also able to make a difference between users, otherwise user A lock record 1 then user B can release it and this can lead to a lot problems.

Since the clients pass their cookies, they will not able to use the lock of any other client. So the database is a kind of stateless.

I think that a Data instance for each client is a pretty solution.

Certianly looks the prettiest of all the three, but there are lof of issues with it. How would I Uniquely identify each client?. I will have to pass some kind of client unique paramater with each call. I will have to rewrite the whole remote server interface stub. I will consider this option.

An other point is the singeton(s), they are nice but they only live once.
Think about.

Sorry I did not understand the problem with singletons. They are going to exist throughout the lifetime of the server...

Thanks.

[Andrew Monkhouse]

Hi Thirumurugan,

Originally posted by Thirumurugan Mylrajan:
I read in Andrew's book that he prefers separate data classes to prevent thread safety issues...

Actually I don't specify my preference

From page 151 of the book:
If we can return a token from the lock method to the client requesting the logical lock, then we can mandate that the client must use that token when performing other operations, including when they release the logical lock.
...
However, our interface requires that our lock method return a Boolean and the releaseDVD method does not allow us to insert a token either, so this is unfortunately not an option for us.

It is only after I have discounted using a cookie because of our specific interface requirements that I start talking about other options (including have multiple Data classes).

Which is still not stating my preference - just clearing up that I havent gotten off the fence yet .

You should also be aware that all we are talking about here is the issue of client identification. This can be (and should be) a seperate topic to one of thread safety. It is possible to have a design that is perfectly thread safe and yet does not identify clients correctly. Likewise it is possible to have a solution that identifies clients perfecty and yet is not thread-safe.

Regards, Andrew

[Mihai Radulescu]

Hi,

About cookies.
Ok that was my fault, because I judge you post from my point of view(or better from my specs point of view). I have no cookies. So if you can use them to id
entify the clients is OK.

About singletons.
If you have a singleton for your FileHander and our LockManager are singletons thy can be use only once with a specified purpose, but if they are not you
can reuse them also in other places/purposes(e.g. you need a report class which read a database file and print its content). The same logic is for the Lock
Manager.
Also you can have more than one server running under the same JVM.

The singleton is the easiest solution but this pays its prise.

Regards M.

[Thirumurugan Mylrajan]

Thank you Andrew and Mihai..

I must admit that I did not go through Andrew's book completely, but just remembered some points from here and there.

Now I am clear about the things.