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.
The problem I see is that calling the lock method from within the update method leaves the potential for somebody to overwrite another person's booking (or even book a deleted record). Consider the following:
Client A checks that record 1 has not been booked
Client B checks that record 1 has not been booked
Client A books record 1 (calls the update() method)
Client B books record 1 (calls the update() method)
Now client A thinks that they have successfully booked record 1, but the database shows that client B owns the record
This problem can be overcome by using the lock() method to logically block one client from even confirming availability the record until the other client has finished.