I've searched the boards for a while and seen a few posts alluding to the same issue but never a conclusive answer.

The application - swing rich client on a single user local db.

In this situation I think a session-per-application is desirable. If I load an entity, say the contact "Tom Hughes", I want only one object instance for that entity at any one time. Therefore if edit 'Tom Hughes" on my search screen, it is updated on my "Favourites Contacts" screen because it is the same object instance. Having a shared instance avoids me having stale data on my application's forms and avoids me having to listen to update events (via the interceptor or event mechanism or other means) and reload my forms as needed - this has a negative impact on performance, robustness and complexity.
I do realise the power of sessions and how they are used, please don't point me to here : http://hibernate.org/42.html#A11
I think though in my single useer db, I don't care about multiple sessions. They only serve to complicate.

Unfortunately I don't think I can implement a session-per-application because of the behaviour of the first level 'cache', ie. the session. That is, entities loaded into the session stay there until the session is closed.

I was thinking it may be possible to write a session that used weak references for all non-dirty entities. Entities could then be garbage collected when my app no longer needed them. I would be willing to contribute this work if feasible.

So the questions,
* I'm not a hibernate expert so are there any flaws in my reasoning?
* Should I be using hibernate this way in a two teir architecture?
* Is there an existing method to manage the first level cache?
* Is the suggestion of a weakly referenced session implementation feasible?

This would be super, super useful and from my research, I'm not the only one having these problems.

thanks,
Tom Hughes