aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes UrlyBird - RMI server and Data design issues Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "UrlyBird - RMI server and Data design issues" Watch "UrlyBird - RMI server and Data design issues" New topic
Author

UrlyBird - RMI server and Data design issues

Thirumurugan Mylrajan
Ranch Hand

Joined: Jan 26, 2006
Posts: 64
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.


SCJP , SCJD. (IBM 142 in progress).
John McBird
Greenhorn

Joined: Jul 05, 2006
Posts: 5
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
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

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 ]

SCJP, SCJD, SCWCD, OCPJBCD
Thirumurugan Mylrajan
Ranch Hand

Joined: Jan 26, 2006
Posts: 64
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
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11509
    
  95

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


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

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
Ranch Hand

Joined: Jan 26, 2006
Posts: 64
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.
 
jQuery in Action, 2nd edition
 
subject: UrlyBird - RMI server and Data design issues