Nice to see that other people have the same troubles ;-}
I designed the client with implicit locking. Therfore, my client interface doens't provide any 'lock' or 'isLocked'-method. I just implemented an 'update', 'find', ..methods. These methods garantee atomic write access by using the 'lock' and 'unlock' of the Data Interface, but hide the locking from the client.
With my design choice I run into trouble when multiple users like to update the same record at time. I found a workaround by rereading the record and compare it with the record from the GUI-table. If these records don't equal, I show a message that the reccord is outdated.
There is still a little risk that both users success at the same time, however, it simplifies the implementation much.
I hope (;-}) that an explicit lock handling on the client is out of the assignement scope. I rather think about making a business layer with the appropriate business logic:
* lock
* test if already booked
* update
* unlock
However, I ran in the same naming interpretation confusion. I think, we just need to document it well, like we must do it for other decitions.
Good luck!
Kuno