generated id not rolled back after transaction rollback

rishi217 · **Joined:** Wed Nov 16, 2005 11:52 am **Posts:** 6

Need help with Hibernate? Read this first:
http://www.hibernate.org/ForumMailingli ... AskForHelp

Hibernate version:3.1.3

id generated with cascading save update not rolled back after transaction rolls back

I have the following problem:

Two classes Person and PersonInfo are mapped, such that Person has a one-to-one mapping to PersonInfo, with a cascading SAVE_UPDATE. I am using @Id @Generated annotation on both classes.

While doing testing I tried to persist a Person object with a violated constraint( not null property ).

The transaction was successfully rolled back and both the Person and PersonInfo object were not persisted.

However the id in PersonInfo is not set back to null, whereas in Person it is set back to null.

How do I fix this problem? I cannot set the null property and try to persist again as hibernate thinks that PersonInfo is persistent and does not find the matching object in the database.

Currently what I am doing is this, after I fix the null property, I make the id for PersonInfo null, before persisting the Person object again.

This is an easy solution for the given case, but I have other classes that have more complicated SAVE_UPDATE cascades, and cleaning those objects would be hard.

Has anyone had this problem before? How can I fix it?

Thank you

vsharma1234 · **Joined:** Mon Jul 31, 2006 2:13 am **Posts:** 1

Surely looks like a hibernate problem and should be fixed in hibernate.

But anyways my sugestion would be to not to use hibernate/db exceptions for business purposes. I.e. validating the correctness of the data should be done prior to sending the request to hibernate.. that way you can show relevent messages to the user too and also keep youself insulated from DB implementations.

Hibernate/DB errors can still occur e.g. optimistic locking exception (and hibernate should do the cleanups of the intermittently assigned ids).
And if this happens you need not return the "corrupted" object graph to the client. But if you are just passing references around then its a tough problem. Maybe, if you have a "version/timestamp" column then you can use that as an indicator for "new" instances by setting unsaved-value to null. In this case hibernate should not look at the PK if the version/timestamp is null.

memelet · **Joined:** Fri Aug 27, 2004 1:59 pm **Posts:** 33

Any update on this? I am having the same issue. Any entity which is persisted due to the need to generate an ID is never rolled back.

memelet · **Joined:** Fri Aug 27, 2004 1:59 pm **Posts:** 33

Any update on this? I am having the same issue. Any entity which is persisted due to the need to generate an ID is never rolled back.

leandro.costa · **Joined:** Wed Jul 31, 2013 8:41 pm **Posts:** 2

old post, but any update on this? I'm using hibernate 4.1.3 with JPA 2 and having this problem.

leandro.costa · **Joined:** Wed Jul 31, 2013 8:41 pm **Posts:** 2

Again, this is my problem.
Please, I need some help. How would you solve this situation?
Of course, it is quite simple to solve it with a single object with no relation (just set ID to null before next try),
but what to do with complex object graphs annoted with CascadeType.PERSIST?

Code:

public <T> T persist(T object) {
    EntityTransaction t = em.getTransaction();
    try {
        t.begin();
        em.persist(object);
        t.commit();
    } catch (PersistenceException e) {
        if (t.isActive()) {
            t.rollback();
        }
        throw e;
    }
    return object;
}

Foo foo = new Foo();

try {
    persist(foo);
} catch (PersistenceException e) { // "integrity constraint violation: NOT NULL check constraint"
    // according to database a required attribute in foo was not setted.
}

// let's set it
foo.setBar("bar");

try {
    persist(foo);
} catch (PersistenceException e) { // "detached entity passed to persist"
    // now the ID is the problem: I think hibernate should reset generated IDs to null when em.persist() fails.
}