何时显式排除乐观锁（Hibernate）？
在什么情况下，通过 Hibernate 从 @OneToMany 关系中显式排除乐观锁定是合适的？
我一直在阅读一篇关于 Hibernate 的文章，基本上说对子实体的任何更新都会导致对父实体的乐观锁定，这通常是不需要的。这里的关键词是通常...任何人都可以更准确地解释何时需要或不需要对这样的关系进行乐观锁定吗？
下面是演示乐观锁排除的代码示例：
// Bars - these are specifically excluded from optimist lock
// for the object, since we don't want to obtain optimistic
// lock when we add a new bar
@OptimisticLock(excluded = true)
@OneToMany
@JoinColumn(name = "FOO_ID", nullable = false, updatable = false)
private List<FooBar> bars = new LinkedList<FooBar>();
Under what circumstances would it be appropriate to explicitly exclude optimistic locking from a @OneToMany relationship via Hibernate?
I have been reading a post on Hibernate which basically says any updates to child entities will cause an optimistic lock on parent entity, which is typically unneeded. The key word here is typically... can anyone explain more precisely when you would or would not need optimistic locking on a relationship like this?
Here is the code example given to demonstrate optimistic lock exclusion:
// Bars - these are specifically excluded from optimist lock
// for the object, since we don't want to obtain optimistic
// lock when we add a new bar
@OptimisticLock(excluded = true)
@OneToMany
@JoinColumn(name = "FOO_ID", nullable = false, updatable = false)
private List<FooBar> bars = new LinkedList<FooBar>();
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
基本上，当父级在逻辑上“拥有”其子级时，换句话说，当父级和子级作为一个整体立即修改时，您需要对一对多关系进行乐观锁定。由以相同形式呈现给用户的
OrderLine组成的Order可以是这种关系的一个示例。否则，当应单独修改子项时，应将它们排除在乐观锁定之外。
Topic和Post就是这种情况的一个例子。从技术上讲，这个问题与关系的方向性有关。乐观锁定的目的是防止丢失修改，因此当可能丢失修改时，您需要为一对多关系启用它。当父级是关系的拥有方时，换句话说，当一对多关系是单向的时，就会发生这种情况（请注意，对诸如
Order-订单行）。在双向一对多关系的情况下，“多”方是关系的拥有方，因此“一”方关系的修改不会影响数据库，因此它们不会丢失。
Basically, you need optimistic locking for one-to-many relationships when parent logically "owns" its children, in other words, when parent and children are modified at once as a whole. An
Orderconsisting ofOrderLines, which are presented to the user at the same form, can be an example of this kind of relationship.Otherwise, when children should be modified individually, they should be excluded from optimistic locking.
TopicwithPosts can be an example of this case.Technically speaking, this question is related to directionality of relationships. The purpose of optimistic locking is to prevent lost modifications, so that you need to enable it for one-to-many relationships when lost modifications are possible. This happens when parent is the owning side of relationship, in other words, when one-to-many relationships are unidirectional (note that it's a natural choice to model relationships such as
Order-OrderLine).In the case of bidirectional one-to-many relationships a "many" side is the owning side of the relationship, so that modifications of relationship at the "one" side doesn't affect the database, therefore they can't be lost.