Thanks again for all your replies. In my opinion a lot of valid arguments have been presented and it has certainly made me think harder about the solution.

I obviously chose a bad title for the post, since it seems to me that some think that I want to implement the part of a database that ensures that two users don't update a row at the same time, i.e. concurrently. This is already handled by any database worth using and that is not what I am trying to prevent. I want to prevent that two users request to view the same row, the first one then updates the row and at some later time (since the page has not been refreshed) the second user overwrites the changes from the first user without ever knowing that the first user made any changes. Sorry that I did not make this clear enough and hopefully this clears up any misunderstandings.

If one of the administrators have a better suggestion for a title for this post, feel free to change it.

Now that I have thought more about the problem, I agree that the optimistic locking strategy seems to be the best solution in most situations, including this one. Hopefully I will get my customer to agree. The reason I think it is the best solution is mainly that it is the least complex one. It only requires to check for conflicts when the user updates, while a locking strategy will require more extensive changes in the application. The locking strategy also requires some cleverness and as SheridanCat pointed out, that is not good when it comes to maintainance. Also the way I plan/planned to implement locking would require some AJAX tricky to work in a way that was transparent to the user and in my limited experience getting AJAX to work flawlessly takes time.

That being said the optimistic locking strategy has some application specific problems that will make it a bit harder than what is already discussed above. I will not bore you with the details.

I don't know which strategy will be used yet since it is not entirely up to me to decide what is an acceptable solution. So it is still interesting to shed more light on the locking solution.

There are two problems that ikegami point out that I am not sure are valid for my solution.

First, the situation where you're trying to lock something that's already locked is hard to handle. If you were to use LOCK TABLE, it would block until the lock is obtained. If you were to use your own locking mechanism, then you'd have to keep trying to lock the data. That could put a heavy load on the DB if multiple clients are trying to lock locked records.

I don't think it is necessary to block or continuesly check if the lock is free. Just give the user a signal that the row is locked. Then open the row in readonly mode or something like that. It would work quite similar to opening a document on a shared disk in windows that another user have opened. The problem will be to get a message to users that have opened it in readonly mode when it is unlocked. This can probably be handled by refreshing the page regularly (for instane once every couple of minutes).

Second, a crashed client can hold a record locked indefinitely. You could timeout locks, but that's dangerous.

I don't see why it is dangerous to timeout locks. In my solution there are no process that run periodically to remove old locks. When you check if a row is locked, locks that are too old will be removed before any checking is performed (I don't think I explained this). Do you still think it is dangerous to use timeouts given these new details?.

Puh! That was a long post, hope it made things a bit clearer. BTW I will post my final solution in this thread when I am done implementing the feature.