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

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?

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

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

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.

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

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.

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