Rollback and the first level cache

gab.co · **Joined:** Mon Dec 15, 2003 3:34 pm **Posts:** 18

Hi everyone

Assuming I have a bean called Person with an assigned id, the following code will throw a NonUniqueObjectException:

Code:

Transaction tx = session.beginTransaction();

Person person1 = new Person(); 
person1.setId(new Integer(1));
session.save(person1);

tx.rollback();

Person person2 = new Person(); 
person2.setId(new Integer(1));
session.save(person2); // throws NonUniqueObjectException

Shouldn't rollback() evict person1 from the first level cache? The only solution I found so far is to manually evict person1 calling session.evict(person1) or session.clear().

Comments from the Hibernate Team would be welcome.

Thanks in advance,
Gabriel.

anthony · **Posted:** Mon Apr 04, 2005 12:13 pm

for the moment persistent objects aren't transactionnal.
When ou call rollback, session is not going to get its previous state, you should discard the session and get a new one.

gab.co · **Joined:** Mon Dec 15, 2003 3:34 pm **Posts:** 18

anthony wrote:

for the moment persistent objects aren't transactionnal.
When ou call rollback, session is not going to get its previous state, you should discard the session and get a new one.

Will it be a future feature?

It seems to me that such behavior compromises the concept of long "application transactions" as described in Hibernate in Action.

Why should we be able to open multiple transactions within the same session if this constraint leaves the session in a dirty state after a rollback?

Thank you.

christian · **Posted:** Mon Apr 04, 2005 2:21 pm

HiA explains clearly that all database transactions in an application transaction should only read data, not write (set FlushMode.NEVER). Hence, there is no rollback - and besides, compensation would have to be done anyway, so you can as well include a fresh Session in your recovery process.