Transaction rollback question

ev9d9 · **Posted:** Wed Dec 29, 2004 4:46 am

Hello,

I'm new to Hibernate so this might be a stupid question, but anyway...

I'm wondering wether or not Hibernate transaction rollback affects persistent objects? Here is a scenario that illustrates my question:

Say I have a fat client that obtains a User object from the database when the user logs into the tool. This User object would be kept around for the duration of the user session with the tool in some globally accessible spot. When the user logs in you would have some code like this:

Code:

Session session=...
Query findUserQuery=session.getNamedQuery("findUserQuery");
findUserQuery.setString("name", name);
findUserQuery.setString("pw", pw);
User user=(User)findUserQuery.uniqueResult();
if (user!=null) {
  GlobalSpot.put("user", user);
}
else {
  //generate some error
}

Now suppose that the tool has a preferences window somewhere that allows the user to update some user prefs, which are stored in the user object. When the changes are applied, we execute some code like this:

Code:

Session session=...
Transaction tx=null;
try {
  tx=session.beginTransaction();

  User user=GlobalSpot.get("user");
  user.setPrefs(newPrefs);

  session.saveOrUpdateCopy(user);

  tx.commit();
}
catch (Exception e) {
  tx.rollback();
}

Suppose now that the saveOrUpdate() call throws an exception. As a result the transaction will be rolled back and the DB will still have the old preferences. However, the user object will not have been rolled back and has the new, unsaved preferences!

Is this normal behaviour? To me this seems a bit strange because that way I still have to do a lot of stuff to do a rollback on the object. This seems like something the OR mapper could do? Or am I just looking at it the wrong way and is this incorrect use of Hibernate?

Any feedback would be much appreciated!

Erwin

max · **Posted:** Wed Dec 29, 2004 5:21 am

hibernate does not rollback the changes in memory since it is impossible to do efficently and safely - think about how we should go about deleting a created object from the memory of JVM ?

If an error occurs during a session - throw the session and related objects away...nothing more nothing less ....it's not that hard if you have proper encapsulation and proper error handling in place (like for any other kind of error handling)

ev9d9 · **Posted:** Wed Dec 29, 2004 5:49 am

That is the answer I expected: throw away the session and all involved objects.

However, since my example was storing the user object in a "global spot", I would also need to throw away that globally accessible object, reloading it from the DB again in a new session. This would imply that the application would not really be able to use objects loaded from the DB freely, keeping references to them and the like.

Would I be correct in saying that persistent objects cannot be used as if they were just normal, in memory objects. The OR mapping done by Hibernate is transparenton a technical level, but conceptually it is not: you need to carefully manage your persistent objects in your application and you cannot just forget about the fact that they are persistent.

Erwin

max · **Posted:** Wed Dec 29, 2004 6:23 am

You are completly correct about the transparency comment (and I seriously don't know of any other framework that allows the kind of transparency you are talking about).

...and yes, you will find people mentioning that persistence can be that transparent - but its not realistic) ....but hey, who knows what tomorrow will bring.

But regarding persisting objects in the "global spot" and you want to restore the state of the object then look at using Session.load(Object object, Serializable id) (but remember to use a new session since your current one is "bad")

But the best thing is to load a new proper instance and reput it in the GlobalSpot and use a notification mechanism to let anyone that might keep the "bad" one around to go fetch it again.