JPA / Hibernate无法理解持久顺序

Question

I'm trying to understand how the jpa/hibernate "magic" really works in practice, to avoid future (and common) pitfalls.

So I created some simple JUnit tests, where the set of instructions is exactly the same, but the call order of em.persist() is different.

Note that I'm using Hibernate 5.2.10 and bean validator 5.2.4 with hibernate.jdbc.batch_size and hibernate.order_inserts (more details on persistence.xml).

You can also access the full code on GitHub

the two test entities:

@Entity
public class Node implements Serializable
{
    @Id
    private long id = System.nanoTime();

    @NotNull
    @Column(nullable = false)
    private String name;

    @OneToMany(mappedBy = "startNode", cascade = ALL, orphanRemoval = true)
    private Set<Edge> exitEdges = new HashSet<>();

    @OneToMany(mappedBy = "endNode", cascade = ALL, orphanRemoval = true)
    private Set<Edge> enterEdges = new HashSet<>();

    public Node() {}

    public Node(String name)
    {
        this.name = name;
    }

    ...
}

and

@Entity
public class Edge implements Serializable
{
    @Id
    private long id = System.nanoTime();

    @NotNull
    @ManyToOne
    private Node startNode;

    @NotNull
    @ManyToOne
    private Node endNode;

    ...
}

tests:

@Test
public void test1()
{
    accept(em ->
    {
        Node n1 = new Node("n11");
        em.persist(n1);

        Node n2 = new Node("n12");
        em.persist(n2);

        Edge e1 = new Edge();
        e1.setStartNode(n1);
        n1.getExitEdges().add(e1);
        e1.setEndNode(n2);
        n2.getExitEdges().add(e1);
        em.persist(e1);
    });
}

@Test
public void test2()
{
    accept(em ->
    {
        Node n1 = new Node("n21");
        em.persist(n1);

        Node n2 = new Node("n22");
        em.persist(n2);

        Edge e1 = new Edge();
        em.persist(e1);  // <-------- early persist call (no exception)
        e1.setStartNode(n1);
        n1.getExitEdges().add(e1);
        e1.setEndNode(n2);
        n2.getExitEdges().add(e1);
    });
    // exception here: java.sql.SQLIntegrityConstraintViolationException: Column 'ENDNODE_ID'  cannot accept a NULL value.
}

@Test
public void test3()
{
    accept(em ->
    {
        Node n1 = new Node("n31");
        Node n2 = new Node("n32");

        Edge e1 = new Edge();
        e1.setStartNode(n1);
        n1.getExitEdges().add(e1);
        e1.setEndNode(n2);
        n2.getExitEdges().add(e1);

        em.persist(n1); // <-------- late persist calls: org.hibernate.TransientPropertyValueException: Not-null property references a transient value - transient instance must be saved beforeQuery current operation : hibernate.model.Edge.endNode -> hibernate.model.Node
        em.persist(n2);
        em.persist(e1);
    });
}

test1 , which follows the canonical order of instructions, obviously passes.

test2 , which calls persist immediately after the constructor call, fails on commit with a database null constraint violation for EDGE.ENDNODE_ID .
I thought this should not happen and I believed that either:

• the exception should be thrown on persist, instead of on commit
• there should be no exception, since, on commit, e1 should be linked with both n1 and n2 .

test3 , which calls persist late, fails directly on em.persist(n1); line (and not on commit).
I thought this should not happen too.
An exception is thrown (by cascade) for e1.endNode referencing a transient entity, while in test2 no exception is called on persist even if e1.endNode is NULL.

Can someone explain WHY test2 exception is thrown on commit and test3 is thrown on persist (while using order_inserts )?

Shouldn't Hibernate cache (and order) insert statements until commit?

---

UPDATE

I don't need a fix , I need an explanation. I'll try to make the questions more clear:

1. T2: why hibernate ignores a @NotNull constraint on persist?
2. T2: why , although issued a e1.setEndNode(n2) , a null reaches the db? shouldn't e1 be managed after calling persist and track end-node n2 ?
3. T3: why hibernate throws an TPVE early (on persist and not on flush/commit)? Shouldn't hibernate wait until flush time to throw the exception? Isn't this in contrast with the behavior in T2? BTW, javadoc of persist does not specify TPVE.

I'll try to answer myself:

1. hibernate tries to postpone the validation as late as possible (perfectly fine with me).
2. I cannot find any reasonable explanation... It simply makes no sense to me.

3. after persist, the managed n1 would have a relation with the transient e1 and such situation has to be avoided.
   Nevertheless I can:

    Node n1 = new Node("n31"); em.persist(n1); Edge e1 = new Edge(); e1.setEndNode(n1); // same situation on this line 

to obtain the exact situation (managed n1 is related to transient e1 ), so there must be another reason.

To cut a long story short, I need to understand the reasons of such, apparently controversial, behaviors and determine if they are deliberate or not (maybe bugs?).

---

Thank you @AlanHay, now it's more clear.
I suppose you are right, it seems that hibernate generates insert statements on persist. And now the order makes sense.

Nevertheless I still think it's controversial and a dumb implementation.

Why on earth would you generate insert statements on persist?
A smart impl should remember managed entities and generate insert statements just before flush/commit, generating up-to-date statements.

And why on earth wouldn't you run bean validator when generating statements?
It's available, and yet it's not used.

A word about order_inserts : it is used to group inserts by table, ie:

insert into Node (id, name) values (1, 'x')
insert into Edge (id, startnode_id, endnode_id) values (2, 1, 3)
insert into Node (id, name) values (3, 'y')

becomes

insert into Node (id, name) values (1, 'x'), (3, 'y')
insert into Edge (id, startnode_id, endnode_id) values (2, 1, 3)

It can be used not only as an optimization, but also to control the statements order (the first block fails, but the second succeeds).
Anyway, in this case, it's irrelevant.

Answer 1

T2: em.persist(entity);

http://docs.oracle.com/javaee/6/api/javax/persistence/EntityManager.html#persist(java.lang.Object)

Make an instance managed and persistent.

Says nothing about when the data will be flushed to the database. In the absence of an explicit flush statement then this will occur when the persistence provider decides: which (in the absence of any query being issued in the same transaction , the results of which may be affected by pending changes) will most likely be when the transaction commits.

http://docs.oracle.com/javaee/6/api/javax/persistence/EntityManager.html#flush()

Synchronize the persistence context to the underlying database.

So you can make T2 fail prior to commit by calling em.persist() and then either calling em.flush() or by issung a query aginst Edges: in the latter case pending changes would be flushed automatically to ensure that the query returned consistent results.

@Test
public void test2()
{
    accept(em ->
    {
        Node n1 = new Node("n21");
        em.persist(n1);

        Node n2 = new Node("n22");
        em.persist(n2);

        Edge e1 = new Edge();
        em.persist(e1);  
        //explict flush : should fail immediately
        //em.flush(); 

        //implicit flush :  should fail immediately
        //Query query = em.createQUery("select e from Edge e");
        //query.getResultList();

        e1.setStartNode(n1);
        n1.getExitEdges().add(e1);
        e1.setEndNode(n2);
        n2.getExitEdges().add(e1);
    });
}

T3: em.persist(n1);

Here we can see that this is a Hibernate exception rather than an SQL exception. At the time of calling persist Hibernate is aware that n1 references the transient instance e1. You either need to make e1 persistent or add @Cascade options to the relationship.

See further The JPA specification:

http://download.oracle.com/otndocs/jcp/persistence-2_1-fr-eval-spec/index.html

3.2.4 Synchronization to the Database

Update

You seem to think that the results you are seeing wuth this usage of the API is "apparently controversial" behaviour and that order_inserts should somehow fix your broken code.

Order inserts is as, far as I can see, a means to optimize the writing of SQL statements generated via a correct interaction with the API for a valid in-memory model : not to fix incorrect usage of the API.

If we suppose that Hibernate generates the buffered SQL statements on the call to persist() (where else would it do it after all) then the behaviour makes perfect sense. At that point it cannot set a value for the null relationship. It seems however that after then adding the relationship you expect that (possibly due to the presence of order_inserts or perhaps regardless of this) it will be smart enough to go back and modify the already generated SQL insert statement.

• T2 > em.persist(e1); > generate an insert statement with endnode_id as null.

• T3 > em.persist(n1); > n1 has a relationship to a transient endNode n2. What do I do with it? There is no cacade so I cannot save it so throw an exception.

Answer 2

I've focused the problem to a minimal example and it's a bug , indeed.

Consider a simple entity Node with two properties:

• name ( required with a @NotNull and the db column is not allowing nulls)
• label ( optional and the db column is allowing nulls)

Then consider this test:

@Test
public void test1()
{
    accept(em ->
    {
        Node n = new Node();
        em.persist(n);

        n.setName("node-1");
        n.setLabel("label-1");
    });
}

test1 will fail with:

Caused by: java.sql.SQLIntegrityConstraintViolationException: Column 'NAME'  cannot accept a NULL value.

The incoherence is in the fact that no consistent behavior is met. A consistent behavior is either one:

• a javax.validation.ConstraintViolationException (for @NotNull ) should be thrown (on persist or flush/commit)
• or test1 should pass

Supposing that the expected behavior is a validation exception being thrown, the validator is executed on the entity on flush/commit time, but at that time the entity has the "name" set.
Then, this leads to an out-of-sync between the entity being validated and the generated statement to be executed, making validation return a false positive.

To show it, consider a second simple test:

@Test
public void test2()
{
    accept(em ->
    {
        Node n = new Node();
        em.persist(n);
    });
}

Correctly, this is failing with:

Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [hibernate.model.Node] during persist time for groups [javax.validation.groups.Default, ]
List of constraint violations:[
    ConstraintViolationImpl{interpolatedMessage='may not be null', propertyPath=name, rootBeanClass=class hibernate.model.Node, messageTemplate='{javax.validation.constraints.NotNull.message}'}
]

On the other hand, supposing that the expected behavior is that test1 should pass, the incoherence is due to statement generation time.

To show it, consider a second simple test:

@Test
public void test3()
{
    accept(em ->
    {
        Node n = new Node();
        n.setName("node-3");

        em.persist(n);

        n.setLabel("label-3");
    });

    Node n = apply(em -> em.createQuery("select x from Node x", Node.class).getSingleResult());

    Assert.assertEquals("label-3", n.getLabel());
}

Even if the test passes, two statements are generated (and executed).

Hibernate: insert into Node (label, name, id) values (?, ?, ?)
Hibernate: update Node set label=?, name=? where id=?

I suppose the first statement is generated on persist and the second on flush/commit; but, in this case, I'm expecting a single insert statement generated immediately after the entity has been validated (then on flush/commit time).

In conclusion, I see two possible solutions:

• run the validator inside persist()
• postpone statements generation to flush/commit time