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

Question

在原始开发人员的许可下，我正在用 Java 重新实现一个旧的 BBS MUD 游戏。目前，我使用 Java EE 6 和 EJB session 外观来实现游戏逻辑，并使用 JPA 来实现持久性。我选择 session bean 的一个重要原因是 JTA。

我对 Web 应用程序更有经验，如果您收到 OptimisticLockException，您只需捕获它并告诉用户他们的数据已过时，他们需要重新申请/重新提交。在多用户游戏中始终以“再试一次”作为响应会带来糟糕的体验。考虑到我预计在一场战斗中有几个人会瞄准一个怪物，我认为 OptimisticLockException 的可能性很高。

我的 View 代码(呈现 telnet CLI 的部分)是 EJB 客户端。我应该捕获 PersistenceExceptions 和 TransactionRolledbackLocalExceptions 并重试吗？您如何决定何时停止？

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

在每个用户命令后坚持是否过度？我是否应该每隔几分钟将整个世界加载到 RAM 中并转储状态？

我是否让我的 session 外观成为一个 EJB 3.1 单例，它可以作为一个阻塞点，从而消除进行任何类型的 JPA 锁定的需要？ EJB 3.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。)有时数据有点陈旧，但这并不重要。如果服务器崩溃，这只会是一个问题，否则您最终会将当前状态获取到数据库中。这不是我们正在谈论的银行间信用转账。

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

这世上除了玩家还有什么需要坚持的？坚持其他所有内容通常会对游戏玩法产生负面影响，因此通常您不想这样做。

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