JPA:OptimisticLockException 和级联

Question

在我当前的项目中，我将 Spring Data JPA 与 Hibernate 一起使用，但认为这是一个更普遍的问题，也应该涵盖“普通”JPA。

我不确定我应该如何处理OptimisticLockException使用 @Version 时.

由于我的应用程序的工作方式，一些关系有 CascadeType.PERSIST和 CascadeType.REFRESH , 其他人也有 CascadeType.MERGE .

在哪里办理OptimisticLockException

据我所知，在服务层处理此问题尤其适用于 CascadeType.MERGE。因为那么有问题的实体可能是需要由另一个服务处理的实体(我每个实体类都有一个服务)。

问题是我正在创建一个框架，因此服务之上没有层，所以我可以将它“委托(delegate)”给我的框架的用户，但这似乎“弱而懒惰”。

确定更改的违规实体和字段

如果发生 OptimisticLockException，如何获取导致问题的实体以及更改了哪些字段？

是的，我可以调用 getEntity()但是如何将其转换为正确的类型，尤其是在使用 CascadeType.MERGE 的情况下？实体可以是多种类型，因此使用 instanceof 的 if/switch想到了，但这看起来像 hell 一样丑陋。

一旦我有了正确的类型，我就需要获取版本之间的所有差异，不包括某些字段，如版本本身或 lastModifiedDate。

在我的脑海里还有 HTTP 409，它指出在发生冲突的情况下响应应该包含冲突的字段。

这一切是否有“最佳实践模式”？

Answer 1

乐观锁定的全部意义在于能够告诉最终用户:嘿，您试图保存这条重要信息，但其他人在背后保存了它，所以您最好刷新信息，决定是否仍然想要保存它并可能输入一些新值，然后重试。

就像 SVN 一样，如果你尝试提交一个文件而其他人之前提交了一个新版本，SVN 会强制你更新你的工作副本并解决潜在的冲突。

所以我会做和 JPA 一样的事情:它让调用者通过抛出异常来决定做什么。此异常应在表示层中处理。