Since Hibernate 5.2.15, OneToMany Childs with

cascade = {CascadeType.ALL}, orphanRemoval = true

are leading to a IntegrityConstraintViolation when deleting the parent if the

hibernate.jdbc.batch_size > 1

Hibernate itself seems to issue the statements in the correct order (see example logs below), but probably because some batch-optimizations the real statements (logged by p6spy) are issued in the wrong order (parent delete first instead of last).

Might be associated with the 5.2.15 change https://hibernate.atlassian.net/browse/HHH-5797

Logs with Hibernate 5.2.15 and batch.size=100

2018-05-24 16:02:35.074 DEBUG [org.hibernate.SQL] delete from T_CHILD1 where ID=?
2018-05-24 16:02:35.074 DEBUG [org.hibernate.SQL] delete from T_CHILD2 where ID=?
2018-05-24 16:02:35.157 DEBUG [org.hibernate.SQL] delete from T_PARENT where ID=? and VERSION=?
2018-05-24 16:02:35.173 INFO [p6spy] #1527170555173 | took 13ms | statement | connection 0|delete from T_PARENT where ID=? and VERSION=?
2018-05-24 16:02:35.173 WARN [o.h.e.j.spi.SqlExceptionHelper] SQL Error: 2292, SQLState: 23000
2018-05-24 16:02:35.173 ERROR [o.h.e.j.spi.SqlExceptionHelper] ORA-02292: Integritäts-Constraint (FK_PARENT_ID) verletzt - untergeordneter Datensatz gefunden

Logs with Hibernate < 5.2.15 OR batch.size=1

2018-05-24 16:04:00.483 DEBUG [org.hibernate.SQL] delete from T_CHILD1 where ID=?
2018-05-24 16:04:00.483 INFO [p6spy] #1527170640483 | took 1ms | statement | connection 0|delete from T_CHILD where ID=?
2018-05-24 16:04:00.483 DEBUG [org.hibernate.SQL] delete from T_CHILD2 where ID=?
2018-05-24 16:04:00.483 INFO [p6spy] #1527170640483 | took 1ms | statement | connection 0|delete from T_CHILD2 where ID=?
2018-05-24 16:04:00.673 DEBUG [org.hibernate.SQL] delete from T_PARENT where ID=? and VERSION=?
2018-05-24 16:04:00.673 INFO [p6spy] #1527170640673 | took 2ms | statement | connection 0|delete from T_PARENT where ID=? and VERSION=?