According to the JavaDoc on Session.refresh(Object):

it should re-read the "state" of the given instance from the underlying database. Particularly, this should be useful after executing direct SQL (eg. a mass update) in the same session.

Now here's my question, if I opened a new session and used it to run a stored procedure which inserted a lot of records, then flushed and closed that session, then afterwards used a ThreadLocal session from a Filter to refresh an object which should contain the new records as part of a collection should I expect to see the new records or not? At present I do not and I am guessing this is because the ThreadLocal session does not see the changes, is this correct? In order for the Session.refresh to be able to see the inserted records I would need to have used the same session to perform the call to the stored procedure is that correct?

Thanks,
David

Yes, if session1 and session2 are independant, refreshing session2 won't have any impact on session1.

Okay, I'm using the same session to call the stored procedure and then afterwards to call .refresh(myObject) but I still don't see the records that were inserted by the stored procedure.
The session has been flushed after the running the SP.

Should the Session.refresh method also refresh any collections on the object or just the root object itself?

I can hack around my problem by evicting the ojbect (don't know if I actually need to?) and then opening a new session and reloading it, closing that new session, and then reassociating the object with the ThreadLocal Session before rendering the view. This seems a little bit weird though.

Is that an appropriate approach or did I miss the boat completely?

Thank-you.

Beware ! If you changed your object before sp call, first object changes will overide sp's during flush()


Should be another way. hope first answers will help you to find out why refresh doen't work as expected.

Since the documentation is not explicit on this, I thought I'd post the simple definitive answer:

session.refresh() does not descend into collections (other than to evict() them).


If you want to reload the state of an entire object graph from the database, you must manually traverse and call refresh() on each object (remember to check the object is not transient before calling refresh or you will get a null identifier exception).

Ben

Emmanuel, I think we need here to describe how session.refresh(Object) works? does it extends to all the hierarchy of Object automatically OR should hibernate user dig inside it & refresh each memebr object one by one ?!!

Update: as of newer releases of hibernate, session refresh now DOES seem to refresh collections.

Our jUnit test "testRefreshIsNotRecursive" succeeds with 3.0.1 but fails when we upgraded to 3.0.5.

...so now we have a new jUnit test "testRefreshIsRecursive" ;)

The changelog suggests this was changed in 3.0.3:



Ben

I am having same problem... This is a critical issue in my app. I had to downgrade to 3.0.2.


What's the story with this..

The story seems to be that now it does what it says on the tin.

Shame it didnt do this before because I had to waste a lot of time writing quite a bit of generic tree traversal code (to implement my own recursive refresh).

So how do you refresh the collections so there is no null pointer exception accesing them.

I dont get any NPEs. It works fine for me using 3.0.5. Collections are correctly refreshed. Are you using the latest version 3.0.5? Have you created a simple JUnit test?

If you still have trouble, you will need to post your hib version, mapping file, code etc to the forum and maybe someone will be able to help.