Adam, I think I know what you're getting at: not file or record locking during an update (concurrency in the sense of computer time) but two users working on a document during an overlapping time span (concurrency in real-human time). In that scenario the last user store a record "wins."
In the old proprietary text-management systems -- Atex, for example -- that was easily handled because the editing and storage software were integrated. In the stateless world of the Web, however. you don't actually "log into" a site or "open" a file, but rather send discrete requests to fetch or store data.
What you're going to have to do is work around the problem by adding an "in use" flag -- a column or columns in the database indicating that the item has been checked out. I would do that by saving both the user ID of the editor and a timestamp. When an opened file is stored by that editor, you would unset the flag.
If someone tries to open a file that already has been checked out, go ahead and open it but do so in "read-only mode."
In a Web context that might be accomplished by adding a warning message to the editorial form showing who currently "has" the file, and when it was opened.
You might decide to disable the "submit" button on the editorial form. You also might want to build in some sort of override, because an editor's browser might have crashed. Not that such a thing ever happens. :-)
