【问题标题】:Can Hibernate's @Version consider changes in related entities?Hibernate 的@Version 可以考虑相关实体的变化吗?
【发布时间】:2009-09-09 13:26:23
【问题描述】:

我有 2 个实体:Parent 和 Child 处于一对多关系中。 Parent 是版本化的,即有一个 @Version 字段。我的目标是在Parent 的版本上同步对Parent 和Child 实体的更改。

例如一个线程更新Parent,另一个更新其中一个Childs,这会导致OptimisticLockException。

有可能吗?

我尝试将@PreUpdate 添加到Child,这将增加它的版本Parent,但这并没有帮助,因为Hibernate 似乎只有在它检查版本之后才执行侦听器,因此事务无论如何都会成功提交。

如果可以,如何实现?

【问题讨论】:

    标签: hibernate transactions optimistic-locking


    【解决方案1】:

    您是否尝试将 Child 设为 component 而不是 entity?

    默认的 Hibernate 操作可能更符合您的要求。这个想法是,父母是一个真实的实体,而孩子被认为是一个更大的整体的一个元素。

    在 Hibernate 中,这应该被视为默认的父子关系。 尽管可能,实体之间的父子关系不太自然。

    【讨论】:

    • 我认为这不是我的选择。 Child 是具有 ID 和状态的一流实体,应该保持这种状态。虽然您的想法绝对是一个解决方案,但它不适用于我
    • 好的,我明白了。 . .使用 Hibernate 可能可以满足您的要求,但我不记得您应该尝试什么……抱歉。
    【解决方案2】:

    首先这里有两个问题需要澄清:

    1. 我认为您正在尝试捕获对特定子实例所做的更新,而不是集合修改(例如,添加新子实例/删除旧子实例)。后者默认会增加父母的版本。

    2. 当您说“一个线程更新父线程”和“另一个线程更新子线程”时,我假设更改会立即刷新。换句话说,事件的顺序是:父节点被更新并持久化(更改已刷新;事务已提交1);另一个线程尝试更新指向先前版本的父级并失败的子级。如果不是这样,乐观锁定对您没有帮助。

    1 您可以通过设置适当的隔离级别来解决“事务已提交”位,但这可能会导致更多问题,然后在并发环境中解决。您无法解决“立即刷新”要求。

    假设上述假设是正确的,您需要在更新您的 Child 实例之前使用EntityManager.lock() 方法锁定 Parent。详情请见LockModeType 和Hibernate EntityManager docs。

    【讨论】:

      猜你喜欢
      • 2010-09-22
      • 1970-01-01
      • 2021-08-26
      • 2013-10-19
      • 2023-03-22
      • 2019-03-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多