This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
In my URLyBird I was thinking about informing user that between his read operation (the record he sees in the grid) and book operation, someone did something with the record.
In case the record was removed, there is no fear - I can just return RecordNotFoundException but in case update - I think the user should be informed that the record has been modified, because the one he see on the screen (let's say with price $250) could be changed to $1000 for a night - and he booked the room with price not he agreed to. Also this convers the situation in which the record was deleted and then new one was created (with the same record number if your reuse the already deleted records).
I was thinking about creating some kind of MD5/checksum/hashcode for the record the user read and send it to the book operation in service layer. Then in service layer:
- the record is locked,
- the record is read to get the actual version,
- the checksums are compared and if there is no match: unlock record and throw the RecordModifiedException to the GUI,
- the record was not updated.
The user must be informed about this situation and the record in grid must be refreshed.
The only problem is that the user might be prevented to update the record in infinity (if everytime he hits "book" button, someone other updates the record). I don't know if I should accept this situation.
If not, there is other way to solve it - after the records checksums match fail, the record is not unlocked but rather the user is informed about changes in the record. Then, he is presented with the changed one (grid refresh) and decide what to do. If he:
- cancels the operation - the lock is released,
- accepts to book the room - the record gets updated and lock is released.
The problem with this approach is that the user application might crashed and the lock has not been released. In this situation, the record is dead till the end of server execution.
I think the approach is valid, but it is work which is not needed at all, because the assignment does not require this kind of functionality. Introducing functionality which is not required results (or may result) in:
- more bugs
- extra complexity
- more code to maintain
And in the end this extra code may not be used, because adding new records and updating old ones will never be implemented.