如何解决加载实体集合,通过刷新多次保存每个实体
我遇到问题-更新相同实体时出现死锁
我想从实体列表中实时更新单个实体上的状态。
我正在为此使用JpaRepository。
简化流程:
class Entity {
Set<SubEntity> subEntities;
class SubEntity {
String status;
}
}
---
var entities = EntityRepository.loadAll();
for (var entity : entities) {
for (var subEntity: entity.getSubEntities()) {
subEntity.setStatus("Prepared for execution"); // In actuality small amount of logic
EntityRepository.saveAndFlush(entity)
subEntity.setStatus("Whatever 2"); // In actuality big piece of logic which will save or save-and-retry. Executes logic in lambda; and saveAndFlush is passed as lambda as well "after execution"
EntityRepository.saveAndFlush(entity)
}
}
真实代码与上面的代码非常相似。执行此操作使我陷入僵局
2020-08-11 14:42:40.759 UTC [1718] ERROR: deadlock detected
2020-08-11 14:42:40.759 UTC [1718] DETAIL: Process 1718 waits for ShareLock on transaction 74137; blocked by process 1717.
Process 1717 waits for ShareLock on transaction 74138; blocked by process 1716.
Process 1716 waits for ExclusiveLock on tuple (6,51) of relation 17539 of database 16385; blocked by process 1718.
Process 1718: update process_step set modify_date=$1 where day=$2 and step_name=$3
Process 1717: update process_step set modify_date=$1,status=$2 where day=$3 and step_name=$4
Process 1716: update process_step set modify_date=$1,status=$2 where day=$3 and step_name=$4
2020-08-11 14:42:40.759 UTC [1718] HINT: See server log for query details.
2020-08-11 14:42:40.759 UTC [1718] CONTEXT: while locking tuple (6,51) in relation "process_step"
2020-08-11 14:42:40.759 UTC [1718] STATEMENT: update fees.process_step set modify_date=$1 where day=$2 and step_name=$3
2020-08-11 14:42:40.763 UTC [1717] ERROR: deadlock detected
2020-08-11 14:42:40.763 UTC [1717] DETAIL: Process 1717 waits for ShareLock on transaction 74138; blocked by process 1716.
Process 1716 waits for ExclusiveLock on tuple (6,51) of relation 17539 of database 16385; blocked by process 1719.
Process 1719 waits for ShareLock on transaction 74137; blocked by process 1717.
Process 1717: update process_step set modify_date=$1,status=$2 where day=$3 and step_name=$4
Process 1719: update process_step set modify_date=$1,status=$2 where day=$3 and step_name=$4
2020-08-11 14:42:40.763 UTC [1717] HINT: See server log for query details.
2020-08-11 14:42:40.763 UTC [1717] CONTEXT: while updating tuple (6,53) in relation "process_step"
2020-08-11 14:42:40.763 UTC [1717] STATEMENT: update process_step set modify_date=$1,status=$2 where day=$3 and step_name=$4
2020-08-11 14:42:41.763 UTC [1716] ERROR: deadlock detected
2020-08-11 14:42:41.763 UTC [1716] DETAIL: Process 1716 waits for ShareLock on transaction 74139; blocked by process 1719.
Process 1719 waits for ShareLock on transaction 74138; blocked by process 1716.
Process 1716: update process_step set modify_date=$1,status=$2 where day=$3 and step_name=$4
2020-08-11 14:42:41.763 UTC [1716] HINT: See server log for query details.
2020-08-11 14:42:41.763 UTC [1716] CONTEXT: while updating tuple (6,51) in relation "process_step"
2020-08-11 14:42:41.763 UTC [1716] STATEMENT: update process_step set modify_date=$1,status=$2 where day=$3 and step_name=$4
为什么呢? saveAndFlush是否不应该在冲突发生之前解决它?
还是问题出在不同的交易上?
编辑:而且,它并不总是发生。好像是比赛条件
编辑2:我已批量更新,但我认为saveAndFlush应该有效地忽略它?
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。