Validation Interceptor and Rollback of Primary Key

Kerstetter · **Posted:** Fri May 27, 2005 4:03 pm

Hibernate version:
3.0.3

I have written an Interceptor to perform invariant checks on flushed entities during "preFlush". If any of the flushed entities are invalid, a RT exception is thrown from this method. However, I have run into a problem in cases where new entities are invalid.

Code:

    public static void saveBank(final Bank bank) {
        HibernateUtil.beginTransaction();
        HibernateUtil.currentSession().saveOrUpdate(bank);
        HibernateUtil.commitTransaction();
    }

The problem is that the primary key is set on the new objects (by hibernate using a hilo algorithm) in the object graph before the preflush call and they are never unset on a validation failure. This causes problems downstream once the user has corrected the problem and attempts to save the changes. At this point, hibernate sees the primary key is already set and attempts to update a row that does not exist.

Perhaps the following code is easier to understand, it too "fails".

Code:

Bank bank = new Bank(); //will fail aba number is not nullable.
HibernateUtil.beginTransaction();
HibernateUtil.currentSession().saveOrUpdate(bank);
assertNotNull(bank.getBankId());
HibernateUtil.rollbackTransaction();
assertNull(bank.getBankId());  //primary key is non-null.

I would think that the rollback would also rollback any changes to the primary key. Is this simply not supported? It is not trivial for me to determine if an insert/update is actually required for all objects in the object graph.

zesj · **Joined:** Tue May 24, 2005 10:19 am **Posts:** 65

from documentation:

Quote:

If you rollback the transaction you should immediately close and discard the current session to ensure that Hibernate's internal state is consistent.

( see http://www.hibernate.org/hib_docs/reference/en/html_single/#manipulatingdata-endingsession-commit)

Kerstetter · **Posted:** Tue May 31, 2005 9:10 am

My original example was not clear that this is indeed a problem between sessions. We do discard the session, but of course we keep the domain objects.

Code:

BankManager.saveBank(bank);
HibernateUtil.closeSession();
bank.setName("required");
BankManager.saveBank(bank);  //fails because an update is attempted because the PK is set, but the row does not yet exist in the database, because of the original validation failure.

Kerstetter · **Posted:** Fri Jun 03, 2005 10:13 am

OK, I guess the simple question is, if an Interceptor throws a CallbackException, should the Hibernate machinery return the entities to their original state, including unsetting any generated primary keys? This was certainly my expectation. Is there documentation on how this is handled?

emmanuel · **Posted:** Mon Jun 06, 2005 6:26 am

No state rollback except for id if needed

hibernate.use_identifer_rollback If enabled, generated identifier properties will be reset to default values when objects are deleted.

Kerstetter · **Posted:** Mon Jun 06, 2005 9:43 am

OK. Thanks. In this case, it would not be appropriate for me to delete the entities, and from my testing, simply enabling this property does not help. I have an alternative, labor-intensive approach that I believe should work. I am going to cache all entities in onSave and then reset their ids during preflush, if I detect a Validation failure during that method.

Kerstetter · **Posted:** Mon Jun 06, 2005 10:06 am

I have taken the liberty of opening a JIRA issue about this, as I think it is an improvement worthy of consideration.

http://opensource.atlassian.com/project ... se/HHH-585