wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes RMI/synchronization issue 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 "RMI/synchronization issue" Watch "RMI/synchronization issue" New topic
Author

RMI/synchronization issue

Richard Solomon
Greenhorn

Joined: Sep 12, 2002
Posts: 11
Good day ranchers
I have been doing some last minute testing on my RemoteData class and have come to the following conclusion (please correct me if I am wrong):
I have a RemoteData class which has the Data class as an instance variable, and we all know what Data looks like, most public methods are synchronized.
No here is the problem: I tested the server with 100 concurrent connections doing adds, finds, modifies etc. Then I abnormally killed all 100 clients. I then waited for the RemoteData's unreferenced() method to be called (implementing Unreferenced) then I start up the 100 clients again.
It seems as if the Data objects monitor has not been released, and one of the previous 100 dead clients still has it.
I was wondering if any of you may have experienced this and know of an elegant way to handle this? or maybe I should re-look my design and not synchronize the Data class.
Will this be an issue in terms of the grading process for the assignment?
Pete Lyons
Ranch Hand

Joined: Aug 18, 2002
Posts: 109
Richard,
Have a look at the earlier posts in this forum about Connection Factories and having 1 remote object shared by all clients vs. having 1 remote object for each client. As Michael Morris points out, having 1 remote object per client solves the unique ID problem as well as giving you a chance to get unreferenced() called on a per-client basis, so you might want to look at that (I think that topic is overall architecture, but I'm certain it has 40+ posts).
I have not turned my assignment in yet, so this is just my personal guess, but it would be very hard for them to do extensive lock testing for a lot of clients. I would bet that at most they will bring up 2 clients, and book a seat on a flight from both, and make sure that the second one goes down by 2 (since it did not notice when the 1st one booked a seat). Without editing your code and putting a Thread.sleep() between lock() and unlock() (which is highly useful - thanks Nate), there's not much they can easily do to really nit pick your lock code. I would bet most of your lock points are determined by just reading your code.
Pete
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: RMI/synchronization issue