I guess I read a few things into the question. My experience is that a "record" is more often than not a series of rows in different tables, and the tricky question in these scenarios is making sure that updates either work or don't work in their entirety. This is what I was meant by the "this is what databases are for" line.
It is practically impossible to maintain a useful, enforceable lock on a record in a web application, given the lack of a persistent connection between the client (browser) and the back end. So you are usually left with two choices:
1. Last one in wins: given that the two users presumably have good reasons for modifying the record in question, let them figure it out if there is a conflict. As long as updates are atomic, consistent, blah, blah this works best.
2. Versioning: Every record has a version number associated with it and the database rejects updates with a version != to what is in there.
The real trick is to set yourself up so that you have a single-writer for any given piece of data in the common case and defer whatever locking is necessary optimistically to the database.
IMO, this is the heart of the problem because it renders pessimistic (what we've used in the enterprise for years) virtually useless.
Fortunately, there are techniques to get around them. Several interesting lines of thought are presented in this thread. Thanks to all who posted them. You gave me quite a bit to think about.