IntegrityConstraintViolation with Cascade Deletes and Batch-Size > 1

Description

Since Hibernate 5.2.15, OneToMany Childs with

are leading to a IntegrityConstraintViolation when deleting the parent if the

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

All Hibernate-Logs, then the p6syp logs
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

One p6spy log after every hibernate log
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_CHILD1 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=?

Environment

None

Activity

Show:
Vlad Mihalcea
June 18, 2018, 8:49 AM

You need to provide a test case for the issue. Otherwise, we don't know the use case which leads to this issue.

Vlad Mihalcea
June 18, 2018, 9:05 AM

This might be a duplicate of HHH-12470 which was fixed and will be released in 5.2.18.

Try it with 5.3.1 or give it a try after 5.2.18 is released as well. If you cannot replicate it on the master brach, it means it's a duplicate and got fixed.

Guillaume Smet
June 22, 2018, 5:21 PM

Hi ,

Could you provide a self contained test case based on our test case template: https://github.com/hibernate/hibernate-test-case-templates/tree/master/orm/hibernate-orm-5 ?

Thanks!

Guillaume Smet
June 27, 2018, 9:33 AM

so you were right about the cause and the issue has already been fixed as part of https://hibernate.atlassian.net/browse/HHH-12470 .

It will be part of 5.2.18.

Assignee

Unassigned

Reporter

Stefan Mueller

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Feedback Requested

2018/06/22

Worked in

5.2.14

Feedback Requested By

Guillaume Smet

Components

Affects versions

Priority

Major
Configure