Hi. I have a simple question regarding transaction rollback.
When I execute the following code:



both persistant classes 1 and 2 are stored in the database. I'm not sure I understand why.
One resolution I found for this is adding transaction1.flush() before transaction1.rollback(). However, I didn't notice any documentation/example in which rollback requried a flush or clear of the session.
Am I doing something wrong or missing something here?

I appreciate the help



Hibernate version: 3.1 final

Mapping documents: using annotations

Name and version of the database you are using: oracle 10g

The generated SQL (show_sql=true):
Hibernate: select ATTR_SEQ.nextval from dual
Hibernate: select ATTR_SEQ.nextval from dual
Hibernate: insert into STATIC_ATTR (CREATION_TIMESTAMP, PARENT_ID, PARENT_TYPE, PRIORITY_WEIGHT, NAME, TYPE, ID) values (?, ?, ?, ?, ?, ?, ?)
Hibernate: insert into STATIC_ATTR (CREATION_TIMESTAMP, PARENT_ID, PARENT_TYPE, PRIORITY_WEIGHT, NAME, TYPE, ID) values (?, ?, ?, ?, ?, ?, ?)

The transaction does not affect local object states or unregister objects that you've registered with the session - it's purely a database level thing. As the newly created object is still part of the session it is written to the database when you perform the commit operation.

thanks for the quick reply.
Just to state my opinion about this, I think it is completely against the "units of work" idea. If I perform some modifications (in this case, save an object to database) in context of a transaction, and then rollback the transaction, I would expect that modification to be undone.
Do you think that performing a flush before a rollback is the correct thing to do (even specifically in this case)?
Moreover, It is stated that transaction.commit also flush the session. maybe transaction.rollback should do the same?

The unit of work idea is typically applied to sessions rather than transactions. See http://www.hibernate.org/42.html for a good explanation.

Yes - but transactions and sessions do depend on each other.

IMHO there are SURPRISES in current design.

What we have:

IF session.flushMode != NEVER
THEN tr.commit() calls session.flush()


(which is quite OK for me).
but I have not seen something like this in tr.rollback()

and it is VERY EASY to make a mistake ( just by calling flush on session
after rollback) to insert inconssistent data into db.
(if only JDBC connections with default autocommit are used)

If I were implementing it I would made tr.rollback() calling session.flush() or even session.clear()

You can use Session.FlushMode = FlushMode.Commit instead of flushing before rollback.