session-per-application in a rich client an antipattern?
by Tom Hughes
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
18 years, 3 months