最佳实践 Hibernate 乐观锁定和 Web 应用程序

Best practice Hibernate optimistic locking and web application

我有一个使用 Tapestry5 (java webframework) 和 Hibernate 制作的 Web 应用程序。现在我正在尝试添加乐观锁定。所以我添加了一个版本属性并且乐观锁定工作,所以这很容易和快速。

但是由于我的 Web 应用程序使用"每个请求的会话"模式,我不确定使用这种乐观锁定的最佳方式是什么。

会发生什么:

UserA 使用加载了 entityA(版本 1)中的值的表单打开页面。

UserB 使用加载了 entityA(版本 1)中的值的表单打开页面。

UserA 更改一些值并提交表单。
-> 新请求检索 entityA(版本 1)并提交更改(entityA 现在是版本 2)

UserB 更改一些值并提交表单。
-> 新请求检索 entityA(版本 2)并提交更改(entityA 现在是版本 3)

应该发生什么

不应提交对 UserB 的更改。但是由于 session-per-request 模式,Hibernate 的乐观锁定错误可能发生的时间窗口减少到仅从提交后的新请求到提交的时间跨度,这不是预期的结果。

可能的解决方案

经过一番研究,我发现了以下内容:

  • 使用实体版本向表单添加隐藏字段

我可以在提交之前使用这个值来设置实体的版本,但是 Hibernate 文档不建议设置这个值。
此外,它仅在实体被分离和重新连接时才有效,因为否则 Hibernate 会忽略手动设置的版本值。

其次,我可以使用此版本值来手动检查表单呈现时的版本是否与提交请求中加载的实体版本相同。如果需要,然后自己抛出一个 OptimisticLockingException。

  • 将分离的实体放入 HttpSession,所以我不必在提交时再次加载它

结论

这些方法有效,但对我来说似乎不太实用并且容易出错。
所以我想知道其他人是如何实现这个问题的。


我最终实现了以下内容:

  • 使用实体版本向表单添加隐藏字段
  • 使用表单 dto 对象
  • 将这些 dto 对象附加到 httpsession(跨多个请求的会话状态)
  • dto 和实际对象之间的手动版本检查

当您分离持久实体只是为了将其传输到 Web 层时,例如创建 DTO 以将对象传输到 Web 层。在这种情况下,我们将使用 getter 和 setter 将 Entity 对象转换为 DTO 对象。

如果您需要使用乐观锁来维护并发控制,您必须在应用程序中维护版本号(这与手动设置版本号不同)。否则,我们无法指示 hibernate 加载记录的旧版本是什么。在hibernate文档中它说"将断开连接的会话保持在持久层附近。使用 EJB 有状态会话 bean 将会话保持在三层环境中。不要将其传输到 Web 层,甚至将其序列化到单独的层,将其存储在 HttpSession." 中,但是所有环境都没有业务层中的 EJB 有状态会话 bean。在这种情况下,我们必须维护版本号。

只要你能维护版本,你就不需要在程序中手动检查版本,如果你让hibernate来做那是很有效的,因为你无法预测你的对象层次结构的深度。

所以你可以做的是,如果你在 web 层使用分离的对象,你必须再次将版本设置为持久实体,然后 hibernate 将处理并发控制。