Comment dois-je gérer la persistance dans un MUD Java? la gestion des OptimisticLockException

Question

Je re-mettre en œuvre un vieux jeu MUD BBS en Java avec la permission des développeurs originaux. Actuellement, je suis en utilisant Java EE 6 avec des façades EJB Session pour la logique du jeu et JPA pour la persistance. Une grande raison pour laquelle je pris les haricots de session est JTA.

Je suis plus expérimenté avec des applications web dans lequel si vous obtenez un OptimisticLockException vous attrapez juste et indiquer à l'utilisateur que leurs données sont obsolètes et ils ont besoin de réappliquer / resoumettre. En réponse à « essayer à nouveau » tout le temps dans un jeu multi-utilisateurs serait une expérience horrible. Étant donné que je me attends plusieurs personnes à cibler un seul monstre lors d'un combat, je pense que la chance d'un OptimisticLockException serait élevé.

Mon code de vue, la partie présentant une CLI telnet, est le client EJB. Dois-je prendras les PersistenceExceptions et TransactionRolledbackLocalExceptions et juste une nouvelle tentative? Comment décidez-vous quand arrêter?

Dois-je passer à verrouillage pessimiste?

persiste après chaque commande utilisateur surpuissant? Dois-je être charger le monde entier dans la RAM et le dumping de l'état toutes les deux minutes?

Est-ce que je fais ma façade de session, un EJB 3.1 singleton qui fonctionnerait comme un goulot d'étranglement et donc d'éliminer la nécessité de faire tout type de verrouillage JPA? EJB 3.1 fonctionnent singletons comme un lecteur multiple / design unique auteur (vous annoter les méthodes que les lecteurs et les écrivains).

En fait, quelle est la meilleure conception et l'API Java de persistance des changements de données hautement simultanées dans une application où il est acceptable de présenter soumettre à nouveau / nouvelle tentative invites à l'utilisateur?

Answer 1

Je ne peux pas empêcher de penser que vous êtes massivement ce qui devrait surcharger être une question simple.

MMOs commerciaux et succès prennent souvent une approche comme celle-ci:

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

Il n'y a pas de données « très simultanées » des changements parce que chaque joueur enregistre ses propres données, à différentes lignes de la base de données. (Dans certains cas, cela est littéralement une ligne - plusieurs jeux commerciaux stocker uniquement les données du joueur comme Blob contre l'ID utilisateur.) Parfois, les données sont un peu fade, mais qui est sans importance. Ce sera seulement un problème si le serveur tombe en panne, car sinon vous finirez par obtenir l'état actuel dans le DB. Ce ne sont pas les virements interbancaires dont nous parlons.

En ce qui concerne les MUD et les jeux BBS, leur algorithme aurait été encore plus simple:

Every few minutes or after a significant action:
    For each property in the player object:
        write a property to the player's file

Encore une fois, il n'y a pas de conflit ici, parce que chaque joueur a son propre fichier.

après chaque commande Persistance utilisateur est en effet surpuissant, à moins que votre jeu est très monétisée et il y a un risque de personnes que vous poursuivre si elles perdent leur +3 Ax de Impressionnant en raison d'un plantage du serveur.

Et quoi d'autre dans le monde ne vous devez persister autre que les joueurs? Il y a des implications de jeu souvent négatives pour tout le reste persistant, donc en général, vous ne voulez pas le faire.

En ce qui concerne l'accès « concurrent » au même monstre, selon votre exemple, il n'a pas d'importance. Si vous avez un seul processus, le monstre devrait être dans la RAM. Votre seul processus qui arrive à arbitrer frapper le monstre et dans quel ordre. Ce n'est pas un emploi pour votre couche de persistance. Gérer la logique du jeu dans le jeu et les résultats persistent.

Answer 2

Si je me souviens bien, la plupart des MUD classiques ne fait charger le monde entier dans la RAM et de vidage de l'état périodiquement. Bien sûr, mes souvenirs sont depuis le jour où une taille de processus de 16MB a été considéré comme terrifiant.