beg*_*er_ 4 jpa optimistic-locking
在我目前的项目中,我使用Spring Data JPA和Hibernate,但认为这是一个更普遍的问题,也应该涵盖"普通"JPA.
我不确定OptimisticLockException在使用时应该如何处理@Version.
由于我的应用程序是如何工作的一些关系,有CascadeType.PERSIST和CascadeType.REFRESH,其他人也有CascadeType.MERGE.
OptimisticLockException据我所知,在服务层处理这个问题不会特别有效,CascadeType.MERGE因为那时违规实体可能是需要由另一个服务处理的实体(我每个实体类都有一个服务).
问题是我正在创建一个框架,因此没有服务上面的层,所以我可以将其"委托"给我的框架用户,但这似乎"软弱和懒惰".
如果发生OptimisticLockException,如何获取导致该问题的实体以及更改了哪些字段？
是的,我可以打电话getEntity()但如何将其转换为正确的类型,特别是如果使用CascadeType.MERGE？该实体可以是多种类型,因此instanceof可以想到if/switch,但这看起来像地狱一样难看.
一旦我有正确的类型,我需要获得版本之间的所有差异,不包括某些字段,如版本本身或lastModifiedDate.
在我的脑海中还有HTTP 409,它表示如果冲突响应应该包含冲突的字段.
所有这些都有"最佳实践模式"吗？
乐观锁定的全部意义在于能够告诉最终用户:嘿,你试图保存这条重要信息,但其他人将它保存在你的背后,所以你最好刷新信息,决定你是否仍然想要保存它并可能输入一些新值,然后重试.
只是SVN喜欢,如果你试着提交一个文件,之前别人犯了新的版本,SVN迫使你更新你的工作副本和甲阶潜在的冲突.
所以我会像JPA那样做:它让调用者通过抛出异常来决定做什么.应在表示层中处理此异常.
| 归档时间： |
|
| 查看次数： |
8365 次 |
| 最近记录： |