Я не могу не чувствовать, что вы чрезмерно усложняете то, что должно быть простой проблемой.
Коммерческие и успешные ММО часто используют такой подход:
Every few minutes or after a significant action:
copy the player data
pass the player data to a background thread
In the background thread:
write each piece of player data to the database
Не существует «одновременных» изменений данных, поскольку каждый игрок сохраняет свои собственные данные в разные строки базы данных. (В некоторых случаях это буквально одна строка - несколько коммерческих игр просто хранят данные игрока как Blob против идентификатора пользователя.) Иногда данные немного устаревшие, но это неважно. Это будет проблемой только в случае сбоя сервера, потому что в противном случае вы в конечном итоге получите текущее состояние в БД. Мы говорим не о межбанковских кредитных переводах.
Что касается игр MUD и BBS, их алгоритм был бы еще проще:
Every few minutes or after a significant action:
For each property in the player object:
write a property to the player's file
Опять же, здесь нет разногласий, потому что у каждого игрока есть свой файл.
Сохранение после каждой пользовательской команды действительно излишним, если ваша игра не очень монетизирована, и есть риск, что люди подадут на вас иск, если они потеряют +3 Axe of Awesome из-за сбоя сервера.
А что еще в мире вам нужно для настойчивости, кроме игроков? Зачастую сохраняются все негативные последствия для игрового процесса, поэтому обычно вы этого не хотите.
Что касается «одновременного» доступа к тому же монстру, как в вашем примере, это не имеет значения. Если у вас есть один процесс, монстр должен быть в оперативной памяти. Ваш единственный процесс определяет, кто может ударить монстра и в каком порядке. Это не работа для вашего уровня постоянства. Управляйте игровой логикой в игре и сохраняйте результаты.