Sai, You have to avoid lengthy and possible blocking operations in event-handling thread. Look here web page So you have to start thread for search flights and booking operations, other way your GUI would not be responsive enough. But anyway the problem I'm describing is that not only own lock should be cleaned but also lock pending requests. The only way to do that avoiding breaking Sun's reqiurements is to interrupt threads waiting to get a lock. Ok, what would happen if you try to book and other client is holding a valid lock on a record you want to modify: 1. If you're not starting a new thread to book (booking in the event-handling thread) your Book button will remain pressed. 2. If you're starting a new thread and then gracefully shutdown you will have pending lock request waiting on the server and unreferrenced will not help since the lock is not obtained yet. Personally, I think it's an overkill for this assignment but the real stuff works this way.
Chingiz: I would spawn a thread for every gui action that may invoke a method on the server if this was a real world application. In that case, an application server will keep track of the clients and thread being spawned on the server side. I wouldn't do it for this assignment for the reason: How do you map the thread that is created by the RMI server to a gui thread (or even gui) to avoid making double reservation for the same person? Even if there is way do it, the implementation would be beyond the reach for a junior programmer. Having a cleanup thread with unreferenced() implementation is the simple way to minimize the waiting time for a client during seats booking.
Cob is sand, clay and sometimes straw. This tiny ad is made of cob: