我应该如何处理Java MUD中的持久性？OptimisticLockException处理

Question

我在Java中重新实现了一个旧的BBS MUD游戏，得到了原始开发人员的许可。目前，我使用带有EJB会话外观的JavaEE6来实现游戏逻辑，使用JPA来实现持久性。我选择会话bean的一个重要原因是JTA。

我对web应用更有经验，在web应用中，如果你得到一个OptimisticLockException，你只需要捕捉它，并告诉用户他们的数据已经过时，他们需要重新申请/重新提交。在多用户游戏中，总是用“重试”来响应，这将是一种可怕的体验。考虑到我期望几个人在一场战斗中瞄准一个怪物，我认为OptimisticLockException的可能性很高。

我的视图代码是提供telnet CLI的部分，它是EJB客户机。我应该捕获PersistenceExceptions和TransactionRolledbackLocalExceptions，然后重试吗？你如何决定何时停止？

我应该切换到悲观锁定吗？

在每个用户命令之后持续使用是不是有点杀伤力？我是否应该在RAM中加载整个世界，并每隔几分钟转储一次状态？

我是否使我的会话外观成为EJB 3.1单例，从而消除了执行任何类型的JPA锁定的需要？EJB3.1单例的功能类似于多个读取器/单个写入器设计(您可以将方法注释为读取器和写入器)。

基本上，对于不能向用户显示重新提交/重试提示的应用程序中的高并发数据更改，最好的设计和java持久性API是什么？

Answer 1

我不禁觉得你把本应很简单的问题搞得过于复杂了。

商业和成功的MMO通常采取这样的方法：

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

没有“高度并发”的数据变化，因为每个玩家都将自己的数据保存到数据库的不同行。(在某些情况下，这实际上是一行-几个商业游戏只是将玩家数据存储为针对用户id的Blob。)有时数据有点陈旧，但这并不重要。只有在服务器崩溃的情况下才会有问题，否则最终会将当前状态保存到数据库中。我们说的不是银行间的信贷转账。

至于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的Axe of Awesome，就会有起诉你的风险。

除了球员之外，你还需要坚持什么？持久化其他所有东西通常会带来负面的游戏影响，所以通常你不想这样做。

至于“并发”访问同一个怪物，根据你的例子，这无关紧要。如果你只有一个进程，那么怪兽应该在RAM中。您的单个进程将仲裁谁将按什么顺序攻击怪物。这不是持久层的工作。处理游戏中的游戏逻辑，并持久化结果。

Answer 2

如果我没记错的话，许多经典的MUD确实在RAM中加载了整个世界，并周期性地转储状态。当然，我的记忆来自16MB的进程大小被认为是可怕的那一天。