— Keep track of records being edited with an "in use" field recording who's editing it. Problems arise in cases the editor goes away or waits too long to unlock.

This approach works well, but the problems you describe usually arise because you've oversimplified it.

What i've seen used highly successfully, is to store the following fields for each editable object in your datamodel:

• lockUser
• lockDate
• modUser
• modDate

By default, these should all be null. when a user "checks out" an item to edit it, you set the first two values. When a user wants to make an update, you verify that their userId matches "lockUser", and update both modUser and modDate. when they "check in" the object after making their changes, you delete both lockDate and lockUser

The added power that this has over a simple "in use" field showing you who is currently editing, is that now you can add features in your app to allow people to "break locks" if they are over a certain age, or only if the modDate is more then N minutes ago. (so it doesn't matter if the person who locked it goes home for the night, or gets hit by a bus, other people can steal the lock)

Of course, lock breaking should be limited by access control.