• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

RMI/synchronization issue

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic