flush() updates to many objects on database

andreas · **Posted:** Fri Sep 26, 2003 9:19 am

I got some very strange behaviour using session.update() and session.flush().

Look at the following example code (o1 and o2 are different objects):

Code:

Object o1 = session.load(Class, 1)
Object o2 = session.load(Class, 2)
o1.setExample("1")
o2.setExample("2")
session.update(o1);
session.flush();

session.rollback();

session.update(o2);
session.flush();
session.commit();

I saw in the DEBUG log messages, that the changes of o1 AND o2 will be written to the database after the first flush(). So the second flush() does nothing. That means, that the rollback after the first flush() restores both objects on the database.
Looking at the code I had expected, that o2 will be changed after executing the code, cause session.update(o2) is executed after the rollback and before the commit.

What can I do, that an object is not written to the database, before I have called session.update(object)?

Thanks in advance.

gavin · **Posted:** Fri Sep 26, 2003 9:21 am

update() is for _detached_ objects, not for objects already associated with the session. Hibernate implements automatic dirty checking.

andreas · **Posted:** Fri Sep 26, 2003 9:27 am

Does this mean, that changes to all objects, that are associated with a Hibernate session, will be written to the database, if the session is flushed()?

gavin · **Posted:** Fri Sep 26, 2003 9:28 am

andreas · **Posted:** Fri Sep 26, 2003 9:32 am

Thanks for the quick response!!!!

Maybe you could give me another short answer:
In the sourceforge forum was a thread about problems using Interceptor.onFlushDirty() and collections. In the thread you wrote, that a "fix" could be implemented in Hibernate 2.1. What's your actual plan about this fix?

gavin · **Posted:** Fri Sep 26, 2003 9:34 am

no plan at this stage

andreas · **Posted:** Fri Sep 26, 2003 9:51 am

Ok, have to find a workaround till than.

Back to the original problem. Would you say evicting the object from the session after the load is a good workaround for preventing the object to be written to the database to early?

Oh, this doesn't work, if I want to get lazy collections of this object after the evict, right?

aibrahim · **Joined:** Fri Sep 26, 2003 11:44 am **Posts:** 13

Hello,

Because I decided to write a generic hibernate audit interceptor for an application I am working on, I had to deal with the fact that the onFlushDIrty method is not called when a collection changes. What I did was not pretty, I just simply added an conditional statement that if the objects attributes were not considered dirty and one of its collections were dirty to call the interceptor. If people are interested I can submit a patch, but I am not sure Gavin will like this kind forcing which doesn't flow smoothly with the rest of the code.

Regards,