This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I have just multi-tested threading of one of my functionality in the network section called bookRoom. Thankfully I have not endured deadlock, but am aware of the nature that threads are issued, i.e. for example thread 23 could run before thread 16. I'm wondering then in a real-world what would happen if say 50 people booked the same room at the same time. I'm using RMI but I still reckon that I could run into the multi-threaded issue discussed earlier ie. the correct customer might not be able to book the room. Is the only way around this to synchronize the business methods in the network? Does this guarantee that the first person who tried to book the room will be guaranteed to book? I have already synchronized the data class methods. Would appreciate people's views about this as I am new to project development.
Ofcourse your concerns are reasonable and you should try to avoid this. I have followed the above steps to resolves this.
The interface which is the gateway between client and sever has the following method
public Hotel synchronizeHotel(Hotel hotel, long userId)
Scenario: 1. Thread A requests lock for record 1 by setting the hotel's status to Lock
2. Server responds back with the updated hotel
3. Client business logic checks whether the returned Hotel has been booked by other user [We suppose that is not]
4. Thread A is now holding the lock and the user is performing changes
5. Thread A proceeds with the booking by invoking again the same method by changing the hotel's flag to update and release the lock for the record
1. Thread B requests lock for record 1 by setting the hotel's status to Lock
2. Thread B is waiting for Thread A to release resources
3. Server responds back with the updated hotel (Including the changes that were made from Thread A)
4. Thread B check whether it has been booked, if not it proceeds with the booking by invoking again the same method by changing the hotel's flag to update. If it is booked the client business logic prevent from rebooking
In this scenario I assume that thread A access first the method
Between calls I ensure that a fresh copy is returned to the client in order to avoid data corruption as you mentioned, although I have found out that I have made a silly mistake in my implimentation.. I hope that it will not cost me.. Anyway when the results are out i will know