I believe that the requirements state that you can assume that at most there will be only one person in the database at a time, I also believe the requirments also stated that is a record was locked, you were to wait until it was unlocked, and consume no CPU Cycles until then, however, with that said, you bring up a good point.
Typically you will be dealing with detached views of data. Think of it like this. On Ebay, you enter your bid 10 seconds before the bidding is over, you get a message back telling you that you are currently the highest bidder, you refresh the browser, only to find that you have lost.
The only way around this would be to hold a lock on the record, which is a bad idea for a number of reasons.
In the project you will be dealing with a detached view of a record, I don't think that there would be a very likely chance that somehow a record would be locked at the same time you are trying to save (update to the db) it, on the other hand, I think it is very likely that you may try to update a record that has already been updated.
Typically applications or frameworks (like Hibernate, etc...) handle this with versioning, (reading a version/update counter, etc...). You are not allowed to modify the db, so, the only way to handle versioning is to, lock the record for update and check the current record values against the original detached view of the data, if the match, great, if they don't, not so great.
I suggested this before (and am doing it in my own project) and it was derided, by those who obviously know more, however, using versioning would take care of your concerns, and also provide a more robust and correct application.