Как я должен обрабатывать настойчивость в Java MUD?Оптимистичная обработка исключений lockexception

Question

Я повторно внедряю старую игру BBS MUD на Java с разрешения оригинальных разработчиков.В настоящее время я использую Java EE 6 с фасадами сеанса EJB для игровой логики и JPA для сохранения.Главная причина, по которой я выбрал сессионные компоненты, - это JTA.

У меня больше опыта работы с веб-приложениями, в которых, если вы получаете исключение OptimisticLockException, вы просто перехватываете его и сообщаете пользователю, что его данные устарели и им необходимо повторно применить / повторно отправить.Постоянный ответ "попробуйте еще раз" в многопользовательской игре привел бы к ужасному опыту.Учитывая, что я ожидал бы, что несколько человек будут нацелены на одного монстра во время боя, я думаю, что вероятность исключения OptimisticLockException была бы высока.

Мой код просмотра, часть, представляющая CLI telnet, является клиентом EJB.Должен ли я перехватывать PersistenceExceptions и TransactionRolledbackLocalExceptions и просто повторять попытку?Как вы решаете, когда остановиться?

Должен ли я переключиться на пессимистическую блокировку?

Сохраняется ли после каждой пользовательской команды перебор?Должен ли я загружать весь мир в оперативную память и сбрасывать состояние каждые пару минут?

Должен ли я сделать свой сессионный фасад синглтоном EJB 3.1, который функционировал бы как ограничительная точка и, следовательно, устранял бы необходимость выполнять какой-либо тип блокировки JPA?Синглтоны EJB 3.1 функционируют как дизайн с несколькими устройствами чтения / записи (вы аннотируете методы как readers и writers).

В принципе, каков наилучший дизайн и java persistence API для высококонкурентных изменений данных в приложении, где неприемлемо предоставлять пользователю запросы на повторную отправку / попытку?

Answer 1

Я не могу избавиться от ощущения, что вы сильно усложняете то, что должно быть простой проблемой.

Коммерческие и успешные ММО часто используют подобный подход:

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

Изменения данных не происходят "одновременно", потому что каждый игрок сохраняет свои собственные данные в разных строках базы данных.(В некоторых случаях это буквально одна строка - несколько коммерческих игр просто хранят данные игрока в виде большого двоичного объекта рядом с идентификатором пользователя.) Иногда данные немного устаревают, но это неважно.Это будет проблемой только в том случае, если сервер выйдет из строя, потому что в противном случае вы в конечном итоге получите текущее состояние в БД.Мы говорим не о межбанковских кредитных переводах.

Что касается игр MUDs и 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 Awesome из-за сбоя сервера.

И что еще в мире вам нужно для упорства, кроме игроков?Сохранение всего остального часто имеет негативные последствия для игрового процесса, поэтому обычно вы не хотите этого делать.

Что касается "одновременного" доступа к одному и тому же монстру, согласно вашему примеру, это не имеет значения.Если у вас есть один процесс, монстр должен находиться в оперативной памяти.Ваш единственный процесс определяет, кто должен поразить монстра и в каком порядке.Это работа не для вашего уровня сохраняемости.Используйте игровую логику в игре и сохраняйте результаты.

Answer 2

Если я правильно помню, многие классические MUD действительно загружали весь мир в оперативную память и периодически сбрасывали состояние.Конечно, мои воспоминания относятся к тому дню, когда размер процесса в 16 МБ считался ужасающим.