Upgrading from Hibernate 5.2 to 5.3: CascadeType.ALL seems to fail

Hibernate ORM
1

I’m currently using Hibernate 5.2 and trying to upgrade step by step to the latest version. When upgrading from 5.2 to 5.3 I run into a weird phenomenon.

Given the following entities (yes, those are about spring batch jobs):


import javax.persistence.CascadeType;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.JoinColumn;
import javax.persistence.ManyToOne;
import javax.persistence.OneToOne;
import javax.persistence.Table;

@Entity
@Table(name = "job__step_execution")
public class StepExecution
{
    @Id
    @Column(name = "step_execution_id", nullable = false)
    private Long stepExecutionId;

    // ... Some other  simple mapped columns here

    @OneToOne(cascade = CascadeType.ALL)
    @JoinColumn(name = "step_execution_id")
    private StepExecutionContext stepExecutionContext;

    @ManyToOne
    @JoinColumn(name = "job_execution_id", nullable = false)
    private JobExecution jobExecution;
    
    // ... just getters and setters here
}

@Entity
@Table(name = "job__step_execution_context")
public class StepExecutionContext
{
    @Id
    @Column(name = "step_execution_id")
    private Long stepExecutionId;

    @Column(name = "short_context")
    private String shortContext = null;

    // One additional unmapped column in the table
    // @Column(name = "serialized_context")
    // private String serializedContext = null;
 
    // ... just getters and setters here
}

one of my integration test that tries to clean up started job executions (always) fails:

Behavior with 5.2:

2022-05-19 10:49:48,136 DEBUG [TestNG-test=Ifa-1] {0c2fb533-87d1-40b1-9418-358b0c9645c3} e.j.s.j.d.i.JobDomainImpl: Found the following contexts for the step execution: [31]
2022-05-19 10:49:48,143 DEBUG [TestNG-test=Ifa-1] {0c2fb533-87d1-40b1-9418-358b0c9645c3} e.j.s.j.d.i.JobDomainImpl: removeById(jobExecutionId) called
2022-05-19 10:49:48,143 DEBUG [TestNG-test=Ifa-1] {0c2fb533-87d1-40b1-9418-358b0c9645c3} o.h.SQL: 
    delete 
    from
        job__step_execution_context 
    where
        step_execution_id=?
2022-05-19 10:49:48,148 TRACE [TestNG-test=Ifa-1] {0c2fb533-87d1-40b1-9418-358b0c9645c3} o.h.t.d.s.BasicBinder: binding parameter [1] as [BIGINT] - [31]
2022-05-19 10:49:48,151 DEBUG [TestNG-test=Ifa-1] {0c2fb533-87d1-40b1-9418-358b0c9645c3} o.h.SQL: 
    delete 
    from
        job__step_execution 
    where
        step_execution_id=?
2022-05-19 18:49:48,152 TRACE [TestNG-test=Ifa-1] {0c2fb533-87d1-40b1-9418-358b0c9645c3} o.h.t.d.s.BasicBinder: binding parameter [1] as [BIGINT] - [31]

Behavior with 5.3:

2022-05-19 10:07:56,023 DEBUG [TestNG-test=Ifa-1] {f3c51736-d50e-4c34-97e6-da32a67b5255} e.j.s.j.d.i.JobDomainImpl: Found the following contexts for the step execution: [31]
2022-05-19 10:07:56,043 DEBUG [TestNG-test=Ifa-1] {f3c51736-d50e-4c34-97e6-da32a67b5255} e.j.s.j.d.i.JobDomainImpl: removeById(jobExecutionId) called
2022-05-19 10:07:56,044 DEBUG [TestNG-test=Ifa-1] {f3c51736-d50e-4c34-97e6-da32a67b5255} o.h.SQL: 
    delete 
    from
        job__step_execution 
    where
        step_execution_id=?
2022-05-19 10:07:56,046 TRACE [TestNG-test=Ifa-1] {f3c51736-d50e-4c34-97e6-da32a67b5255} o.h.t.d.s.BasicBinder: binding parameter [1] as [BIGINT] - [31]
2022-05-19 10:07:56,078 ERROR [TestNG-test=Ifa-1] {f3c51736-d50e-4c34-97e6-da32a67b5255} o.h.e.j.b.i.BatchingBatch: HHH000315: Exception executing batch [java.sql.BatchUpdateException: Key value for constraint (informix.job__step_execution__primary_key) is still being referenced.], SQL: delete from job__step_execution where step_execution_id=?

It seems the CascadeType.ALL is getting ignored, since the StepExecutionContexts referencing the StepExecutions are not getting deleted and consequently the deletion of the StepExecutions fails.

I’ve read the migration guide but I can’t see that one of the changes mentioned there would cause this.

Does anybody happen to know what I am missing here?

2

Can you please also try with 5.6 and check if the problem might be fixed in that version already?

3

Hi, I’m not sure if can try this with 5.6:

Upgrading to 5.6 also forces me to upgrade HSEARCH to v6 and that brings along a lot of major changes. Actually, the whole point of migrating from 5.2 to 5.4 (this was what I originally tried, before I ran into the problem with 5.3 described here) for me is to avoid having to migrate everything at once.

For testing purposes, I could try to eliminate HSEARCH and find out what happens with 5.6. But that would take me a few days and if I the result is that 5.6 fixes this, then I’d end up with the solution I tried to avoid in the first place.

What I can tell you now is that 5.4 behaves like 5.3

4

I’m sorry, but at this point, only 5.6 and 6.0 are “maintained”. The 5.3 version is the product branch which is only maintained for Red Hat customers, so unless you are a customer and open a support ticket about your problem, there is probably nobody from the community that can help you with this.

Now, if you can show me (ideally with a reproducer) that this problem exists on 5.6, we can look into it.

5

I will see if I can find out how 5.6 behaves and let you know.

6

In the meantime, I have tried 5.6: Behaves like 5.3/5.4, but I couldn’t extract a reproducer yet. So, if you require one it will take me some additional time.

7

Thanks for confirming. Yeah, a reproducer would be great!

8

Hi, just FYI:

I won’t file a bug for this one. I made a gamble, deactivated the failing tests, and committet the changes. And, lo and behold, our (extensive) system test suite did not find a single issue. So it seems, that the problems with cascade only arise in unit/integration tests.

I still don’t know what to do with the deactivated tests, but for now I’m happy.

Thanks for your help