Как Hibernate решает порядок обновления / вставки/удаления

проблема, которую вы описываете, не обрабатывается базой данных, и, по моему опыту, не полностью обрабатывается Hibernate.

вы должны предпринять явные шаги, чтобы избежать проблемы.

Hibernate делает некоторую работу за вас. В соответствии с предыдущим ответом Hibernate гарантирует, что в изолированном потоке вставки, удаления и обновления упорядочены таким образом, что они будут применяться в достижимом порядке. Видеть performExecutions (сеанс источника событий) в классе AbstractFlushingEventListener:

выполните все SQL (и обновления кэша второго уровня) в специальном порядке, чтобы ограничения внешнего ключа не могли быть нарушены:

1. вставки, в порядке их выполнения
2. обновления
3. удаление элементов коллекции
4. вставка элементов коллекции
5. удаляет, в порядке они были исполнены

при наличии уникальных ограничений очень важно знать этот порядок, особенно если вы хотите заменить ребенка один ко многим (удалить старый / вставить новый), но как старый, так и новый ребенок имеют одинаковые уникальные ограничения (например, тот же адрес электронной почты). В этом случае вы можете обновить старую запись вместо удаления/вставки, или вы можете смыть после удаления только для продолжения вставки. Для более подробного примера вы можете проверить в этой статье.

обратите внимание, что он не определяет порядок обновления. Изучение кода Hibernate приводит меня к мысли, что порядок обновления будет зависеть от порядка, в котором сущности были добавлены в контекст сохранения,не порядок их обновления. Это может быть предсказуемо в вашем коде, но чтение кода Hibernate не оставило меня чувство, что я буду полагаться на этот заказ.

есть три решения, которые я могу думать из:

1. попробуйте спящий режим.order_updates на правда. Это должно помочь избежать взаимоблокировок при обновлении нескольких строк в одной таблице, но не поможет с взаимоблокировками в нескольких таблицах.
2. Сделайте ваши транзакции принять PESSIMISTIC_WRITE блокировка на одном из объектов перед выполнением каких-либо обновлений. Какой объект вы используете, будет зависеть от вашей конкретной ситуации, но пока вы гарантируете, что объект выбран последовательно, если существует риск взаимоблокировки, это заблокирует остальную часть транзакции до тех пор, пока блокировка не будет получена.
3. напишите свой код, чтобы поймать тупики, когда они происходят, и повторите попытку разумным образом. Компонент, управляющий повторной попыткой блокировки, должен находиться за пределами текущей границы транзакции. Это связано с тем, что неудачный сеанс должен быть закрыт, а связанная транзакция должна иметь поддержку отката. В в этой статье вы можете найти пример автоматическая повторная попытка аспекта AOP.