Hello,

I'm puzzled by the following point :
Evicting an entity after an update but before flushing causes no update at all. Is this by design ? If an update is called the on the entity, to me the entity should be saved no matter what (thus regardless of eviction).

Dept d10 = (Dept) fSession.load(Dept.class, new Integer(10));
d10.setName(d10.getName() + "1");
fSession.update(d10);
fSession.evict(d10);
fSession.flush();
fSession.connection().commit();

Thanks for your insigths.

Alain.

Well, evict() removes the object from the Session, thus making it non-transactional. I'd say this is the expected behavior.

It's a common case to fush before evicting to prevent update loss.

Ok thanks for you posts. I see your point, but what I don't get then is the difference between calling an update() or letting automatic persitence do its work. To me,　calling evict would unlist an entity for automatic persistence but would not prevent the entity from being updated if update is called.

Thanks.

Alain

You only need to call update if you have an object modified outside of a session scope. If you have an object attatched to a Session and modify it, it is allways updated by dirty checking.

AUTO-FLUSH
having modified an object in the session, it will be persisted automatically after session is closed, or flush() is called. You don't need save() or update()

NO AUTOMATIC FLUSHING
modifying an entity won't lead to automatic persistance. only if you call flush() explicitly the changes are written to the db.
If you make changes to an entity, close a session without calling flush(), keep a reference to this object and than open a new session you can persist those changes by calling update(obj); a simple flush() won't persist entity-changes done in a former session.

EVICT()
will abandon all changes to an entity since last flush()