受欢迎的模板网站建设好的建网站的公司

受欢迎的模板网站建设,好的建网站的公司,华强北网上商城,中国免费的企业名录—— clear() 一个集合#xff0c;为什么引发 OptimisticLockException 和数据库死锁#xff1f;这是一次看似“新增 / 查询”的普通业务操作#xff0c;却最终演变成 Hibernate 乐观锁异常 MySQL 死锁 批量更新失败 的连环事故。一、问题现象线上频繁出现如下异常#x…—— clear() 一个集合为什么引发 OptimisticLockException 和数据库死锁这是一次看似“新增 / 查询”的普通业务操作却最终演变成Hibernate 乐观锁异常 MySQL 死锁 批量更新失败的连环事故。一、问题现象线上频繁出现如下异常javax.persistence.OptimisticLockException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1伴随的数据库日志还有Deadlock found when trying to get lock; try restarting transaction SQL: delete from km_agreement_review_areader where fd_source_id?诡异点在于表面调用的是新增审计意见 / 新增参数堆栈中指向的是find()查询实际报错却是update / delete涉及的表包括km_agreement_review_areaderlbpm_execution怎么看都不像是一个地方的问题。二、第一个误区find / insert 不会触发乐观锁这是一个非常常见的误区。在 Hibernate / JPA 中只要触发了 flush所有被托管managed的实体都会被统一同步到数据库。也就是说insert A find B在 Hibernate 内部真实执行顺序是flush Session ├─ update / delete / insert之前积攒的 └─ 然后才是 find B异常只是“挂”在 find 上真正出问题的是 flush 里的 update / delete。三、真正的导火索BaseAuthModel 里的clear()所有业务 Model 都继承了一个公共父类public abstract class BaseAuthModel { protected List authAllReaders; protected void recalculateReaderField() { if (authAllReaders null) { authAllReaders new ArrayList(); } else { authAllReaders.clear(); // 关键代码 } // 重新 add 各种 reader authAllReaders.add(getDocCreator()); ... } }这一行代码看起来极其“正常”authAllReaders.clear();但在Hibernate 眼里这是一个非常危险的操作。四、Hibernate 视角clear() 到底干了什么假设映射关系是OneToMany JoinColumn(name fd_source_id) private ListReader authAllReaders;那么authAllReaders.clear();在 Hibernate 中等价于delete from km_agreement_review_areader where fd_source_id ?如果接下来你又authAllReaders.add(...) authAllReaders.add(...)Hibernate flush 时会执行delete from km_agreement_review_areader where fd_source_id ? insert into km_agreement_review_areader ... insert into km_agreement_review_areader ...五、为什么会死锁关键点fd_source_id是外键当多个并发请求同时操作同一个业务对象时线程 Aclear → delete持有子表行锁线程 Bclear → delete等待线程 A后续 update 父表 / execution线程 B持有另一批锁典型的 InnoDB 死锁模型DELETE 子表 → UPDATE 父表 → DELETE 子表另一个事务六、为什么又会触发 OptimisticLockException系统中只有一个地方配置了 versionversion namelockerVersion columnfd_locker_version typelong/配置在lbpm_execution表。而问题在于lbpm_execution在流程执行时早已被加载进 Sessionclear / add Reader 的过程中execution 被标记为 dirtyflush 时 Hibernate 会顺带执行update lbpm_execution set fd_locker_version fd_locker_version 1 where fd_id ? and fd_locker_version ?如果前面发生了死锁回滚并发已更新行被别的事务影响 update 0 行 Hibernate 判定并发冲突 抛OptimisticLockException七、为什么堆栈看起来“很乱”因为这是统一 flush 导致的错觉报错点挂在find()实际执行的是delete 子表update executionHibernate不会告诉你是哪一个实体被判定 dirty这也是 Hibernate 最反直觉的地方之一。八、问题的本质总结一句话这是一个典型的ORM 管理集合 clear 并发 version共同作用下的“架构级事故”九、解法一最推荐绕过 ORM 管理这个集合❌ 错误姿势当前做法OneToMany private List authAllReaders;并对其clear() add()✅ 正确姿势 1不做批量异常在新增只做增量这里有现成方案可以关注后续.....,public void update(IBaseModel modelObj) throws Exception { IFieldsCalculator fieldsRecalculator modelObj.getFieldsCalculator(); if(fieldsRecalculator!null){ fieldsRecalculator.recalculateFields(); }else{ modelObj.recalculateFields(); } //modelObj.recalculateFields(); afterRecalculateFields(modelObj); getHibernateTemplate().saveOrUpdate(modelObj); }model 实现接口IFieldsCalculator fieldsRecalculator modelObj.getFieldsCalculator();完成model 的可阅读者的增量更新。十、为什么这是“无解但必须改”的问题因为BaseAuthModel 是全局父类clear() 是高频路径并发下必然出现死锁乐观锁冲突Hibernate 在这里帮不了你必须从 ORM 设计上规避十一、最终总结Hibernate 非常适合“领域模型”但需谨慎操作“权限计算 / 批量 clear 重建”这种模型这次问题的真正收获不是“修一个 bug”而是明确了哪些集合不该交给 ORM 管明确了clear() 是 ORM 世界的核按钮明确了version 不该用在流程执行上下文上