
您描述的问题不是由数据库处理的,根据我的经验,Hibernate也不能完全解决该问题。
您必须采取明确的步骤来避免出现问题。
Hibernate为您完成了一些工作。按照前面的答案,Hibernate确保在单独的刷新中按一定的顺序对插入,删除和更新进行排序,以确保按可实现的顺序应用它们。请参见AbstractFlushingEventListener类中的performExecutions(EventSource会话):
以特殊顺序执行所有SQL(和二级缓存更新),以免违反外键约束:
- 按执行顺序插入
- 更新
- 删除收集元素
- 插入收集元素
- 按执行顺序删除
当具有唯一性约束时,了解此顺序非常重要,尤其是如果您要替换一对多子代(删除旧的/插入新的)时,新旧子代共享相同的唯一性约束(例如,相同的电子邮件地址)
)。在这种情况下,您可以更新旧条目,而不是删除/插入,或者可以仅在删除后刷新,然后继续插入。有关更详细的示例,请查看本文。
请注意,它没有指定更新顺序。检查Hibernate代码使我认为更新顺序将取决于在实体被添加到持久化上下文中,为了在 不
他们更新的顺序。这在您的代码中可能是可以预见的,但是阅读Hibernate代码并没有让我觉得我会依赖该顺序。
我可以想到三种解决方案:
- 尝试将hibernate.order_updates设置为 true 。当同一张表中的多行被更新时,这应该有助于避免死锁,但对于跨多个表的死锁却无济于事。
- 在进行任何更新之前,使您的事务对一个实体使用PESSIMISTIC_WRITE锁。您使用哪个实体取决于您的具体情况,但是只要确保在存在死锁风险的情况下始终选择一个实体,这将阻塞其余事务,直到获得锁为止。
- 编写代码以在出现死锁时捕获死锁,然后以明智的方式重试。管理死锁重试的组件必须位于当前事务边界之外。这是因为必须关闭失败的会话,并且回退关联的事务。在本文中,您可以找到自动重试AOP方面的示例。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)