I think this is an issue where you haven't committed your transaction yet, and therefore the database still has the old data, and when you call refresh, Hibernate queries the database and gets the old values.
So I have two points.
1. You are in the same
Unit of Work where you changed the Passenger object which is in the "Car", so why do you have to refresh, your
Java Objects already have the most up to date data. Now, if you try to do a session.flush, which will send the change back to the database, (As long as you modified the Passenger object when it is in a persistent state), then call refresh,
you should see the changes.
2. Why do you need to call refresh? I have yet to come across a use case where I needed to do that, unless I rolled everything back, and wanted my Java objects to go back to the exact state of the database.
And you had this question "then how am
I better off than I used to be with plain old JDBC. "
How about removing that 30% of code that is all JDBC and a pain to maintain? Regardless of this issue, that alone would make me jump away from JDBC. Way too much code to write and maintain, and it isn't my Business Logic. And having to write code to transform the ResultSets into my actual Java Objects, and having to figure out how to do Java inheritance transformations, etc. And having to implement my own Caching mechanism, and dirty reading, so that I know exactly what I need to send back to the database after my unit of work. Handling Transactions on my own, especially two phase commits.
Mark