Как говорит Майкл Дж. В., выигрывает последний - если у вас нет механизма блокировки или логики приложения для решения этого случая.
Механизмы блокировки имеют тенденцию резко снижать производительность вашей базы данных.
http://dev.mysql.com/doc/refman/5.5/en/internal-locking.html дает обзор параметров в MySQL. Однако описанный вами сценарий - доступ администратора к записи, блокировка этой записи до тех пор, пока они не изменят запись - вызовет все виды проблем с производительностью.
Альтернативой является проверка «грязной» записи перед обратной записью. Псевдокод:
User finds record
Application stores (hash of) record in memory
User modifies copy of record
User instructs application to write record to database
Application retrieves current database state, compares to original
If identical
write change to database
If not identical
notify user
В этой модели смена администратора вызовет поток «уведомить пользователя»; Ваше приложение может решить прекратить запись или заставить пользователя обновить запись из базы данных перед ее изменением и повторной попыткой.
Больше кода, но гораздо меньше вероятность возникновения проблем с производительностью / масштабируемостью.