What you are dealing with is essentially the persistence context. The primary reason to retain these objects from Hibernate API user point of view is the so called application transactions. Most of the time it is just not practical to retain a valid Hibernate (and DB) session for the full time of an operation, especially if it involves conversations with a user. Perfect example is a user who has been presented with a huge form where he can edit certain properties of an object. You definitely do not want to keep a session open for the whole time he makes his edits.
In broader terms having a persitence context is essential for any ORM solution. As described in details here:
The persistence context cache sometimes helps avoid unnecessary database traffic; but, more important, it ensures that:
The persistence layer isn’t vulnerable to stack overflows in the case of circular references in a graph of objects.
There can never be conflicting representations of the same database row at the end of a unit of work. In the persistence context, at most a single object represents any database row. All changes made to that object may be safely written to the database.
Likewise, changes made in a particular persistence context are always immediately visible to all other code executed inside that persistence context and its unit of work (the repeatable read for entities guarantee).
You don’t have to do anything special to enable the persistence context cache. It’s always on and, for the reasons shown, can’t be turned off.
The persistent cache is never cleared or flushed like sessions, and for the above reasons you should not force it to do so. Use lock or saveOrUpdate to reattach your entities. If you must do something, of course you can start cloning your object, restarting the persistence context, etc, but these are likely not clean solutions.