• 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

Anyone use a new thread for each booking request ?

 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Before my booking method uses only one single thread, so when the database is locked up, any attempt to lock a record will have to wait forever, and eventually the application got frozen until someone removes the lock.
So I create a new thread for each book request. when i test it
i use a for loop as follows
for (int i=0; i < 30; i++) {
BookingThread thread = new BookingThread(some parameters...);
thread.start();
}
So eventually i booked the same record 30 times. I have 2 client booking the same record, so if i booked 1 ticket, the total should went down by 60 tickets. Both client has been successfully booked some records, but after somewhere around 20-30 tickets being booked, i receive an error message of :
Connection refused to Host: 216.XxX.XXX.XX; nested exception is: java.net.ConnectException: Connection Refused: No further information
Any one know what this mean ?
is it a limitation on total number of threads accessing RMI ?
Or is it the problem with my testing approach ?
Or is it purely my lock mechanism problem.
My lock mechanism works when booking is implemented in one single thread, even when more than 6 client is accessing the same record. It is just that the application will hang for a while until it sucessfully lock a record (2-3 seconds). But like i say, if someone lock the entire database and not unlocking, the program will hang forever

Thanks in advance
Karl
 
Karl Fu
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One other thing, in my implementation, each client communicate with its own server-side object which extends UnicastRemoteObject. Should this object behave just like other remote object that binds to the registry ?
 
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First of all, I did not see any reason to create any threads since I used RMI. RMI did that for me on the server side.
Secondly, to book more that one seat, you still just call modify() one time. Did you do the loop just for testing?
Third, on the server, the same object gets used, it is just that multiple threads are using the same object.
Fourth point, your server should not lock up when used correctly. You might want to add a background task on the server (I used TimerTask) to clean up any stale locks that were caused by client disconnections.

[This message has been edited by Rick Fortier (edited June 29, 2001).]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic