我应该如何处理Java MUD中的持久性？ OptimisticLockException处理
作者：互联网
经过原始开发人员的许可,我正在用Java重新实现旧的BBS MUD游戏.目前,我将Java EE 6与EJB Session外观一起用于游戏逻辑,而将JPA用于持久性.我选择会话bean的一个重要原因是JTA.
我对Web应用程序比较有经验,在Web应用程序中,如果您获得OptimisticLockException,则只需捕获它并告诉用户其数据已过时,则需要重新应用/重新提交.在多用户游戏中始终以“重试”响应会带来可怕的体验.考虑到我希望在战斗中有几个人瞄准一个怪物,因此我认为OptimisticLockException的可能性很高.
我的视图代码(呈现telnet CLI的部分)是EJB客户端.我应该捕获PersistenceExceptions和TransactionRolledbackLocalExceptions并重试吗？您如何决定何时停止？
我应该切换到悲观锁定吗？
在每个用户命令过度杀伤之后仍然存在吗？我是否应该每隔几分钟就将整个世界加载到RAM中并转储状态？
我是否使会话外观成为EJB 3.1单例对象,它会成为瓶颈,因此消除了进行任何类型的JPA锁定的需要？ EJB 3.1单例功能充当多个读取器/单个写入器设计(您将方法注释为读取器和写入器).
基本上,对于不允许向用户显示重新提交/重试提示的应用程序中的高度并发数据更改,最好的设计和Java持久性API是什么？
解决方法:
我禁不住觉得您正在使应该简单解决的问题变得过于复杂.
商业和成功的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
没有“高度并发”的数据更改,因为每个玩家都将自己的数据保存到数据库的不同行中. (在某些情况下,这实际上是一行,一些商业游戏只是将玩家数据作为Blob存储在用户ID上.)有时数据有些陈旧,但这并不重要.如果服务器崩溃,这只会是一个问题,因为否则,您最终会将当前状态存储到数据库中.这不是我们正在谈论的银行间信贷转移.
至于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 Awesome,否则有人会起诉您.
而除了玩家之外,您还需要坚持什么呢？持久保留其他所有内容通常会对游戏产生负面影响,因此通常您不希望这样做.
按照您的示例,对于“并发”访问同一怪物,这没有关系.如果只有一个进程,则怪物应该在RAM中.您的单个过程可以仲裁谁击中怪物以及以什么顺序击中怪物.这不是您的持久层的工作.处理游戏中的游戏逻辑并保持结果.
标签：mud,jpa,optimistic-locking,java 来源： https://codeday.me/bug/20191024/1918427.html