I've noticed that even if I do transaction.rollback() after a Session.saveOrUpdate(), the changes don't seem to roll back. Does this imply that saveOrUpdate() commits a transaction and moves the "checkpoint" position to the current position?

Is there anything else that could be going on which would explain why invoking Transaction.rollback() would not prevent from changes to the underlying database? I don't see myself calling Session.commit() anywhere before the rollback.

Gili

Ok, here's an update:

I execute the following code:

List rootThemes = session.find("from com.tog.desktopbeautifier.shared.Theme where parent_id is null");
rootThemes = session.find("from com.tog.desktopbeautifier.shared.Theme where parent_id is null");

Hibernate dies on the second line (which is identical to the first line) because all of a sudden, Theme.name="" and Theme.parent_id="NULL" in the database. In other words, for some unknown reason, session.find() is alternating values inside the database (!!). This shouldn't be!

I can provide you with the sources for Theme and information about my underlying database. Can you please let me know what could possibly be causing this?

For line one, Hibernate generates the following code:

Hibernate: select theme0_.id as id, theme0_.name as name from theme theme0_ where (parent_id is null )
Hibernate: select children0_.id as id__, children0_.parent_id as parent_id__, children0_.name as name__, children0_.id as id0_, children0_.name as name0_ from theme children0_ where children0_.parent_id=?
Hibernate: select children0_.id as id__, children0_.parent_id as parent_id__, children0_.name as name__, children0_.id as id0_, children0_.name as name0_ from theme children0_ where children0_.parent_id=?
Hibernate: select children0_.id as id__, children0_.parent_id as parent_id__, children0_.name as name__, children0_.id as id0_, children0_.name as name0_ from theme children0_ where children0_.parent_id=?
Hibernate: select children0_.id as id__, children0_.parent_id as parent_id__, children0_.name as name__, children0_.id as id0_, children0_.name as name0_ from theme children0_ where children0_.parent_id=?

For line two, Hibernate generates the following code:

Hibernate: update theme set parent_id=null, name=null where parent_id=?

The second command is obviously what is clobbering values in the database. The question is, why is Hibernate generating this? Any ideas?

Gili

Ok, this issue seems related to the user of Collections under Hibernate. It seems to be caused by the fact that I return a clone() from Theme.getChildren(). Hibernate doesn't seem to like that.

Gili

The original question still holds.

Does saveAndUpdate() commit a transaction? Is there a way to saveAndUpdate() which gets rolled back if tx.rollback() occurs? Specifically, if I want to add a new object to the database, the only way I know of is to call saveAndUpdate() on it. How would one conditionally add an object such that it could get removed on rollback()?

Thanks,
Gili

saveOrUpdate doesnt commit. It simply tells hibernate that you wish to persist the state of the object whether the object is transient or detached.

tx.rollback() is a different beast. That is a way to tell the database that you wish to undo all data manipulations performed on the database within the scope of that transaction as bounded by tx.begintransaction and tx.commit

You have to keep in mind what strategy you're using for transaction management. Further, you have to keep in mind the default behavior of your database. For example, mysql commits each query as it comes in by default so you have to explicitly set it up to behave as you expect. Oracle on the other hand (I think) only commits once explicity told to by default.

Im not an expert in the area but hopefully that helps a little. What you really need to keep in mind is that session.save()/saveOrUpdate() have very different purposes than tx.commit() type operations.


I'd have to recommend you read the entire Hibernate reference and Hibernate in Action. That will help you to keep the concepts seperated.

Also, it's very beneficial to read the documentation associated with your database as well as your application server (if applicable).

Good luck
Joe

Correct me if I'm wrong, but are you saying that Transaction.commit()/rollback() is mutally exclusive to Session.saveOrUpdate()? I thought the transaction is a layer that fits on top of the session and that regardless of how the underlying database handles queries (i.e. MySQL commits on every query) Transaction.rollback() will always roll back to either the initial session state or the last checkpoint position. I read the Hibernate documentation a while back and remember getting such an impression. Am I wrong?

Gili

question: have you explicitly called "beginTransaction"?

Yes, I call:

try
{
session = sessionFactory.openSession();
tx = session.beginTransaction();
tx.commit();
}
catch (HibernateException e)
{
if (tx!=null)
tx.rollback();
}
finally
{
if (session!=null)
session.close();
}

Is this correct?

Gili