We are using hibernate with a single user swing gui. Essentially we want to use lazy loaded associations and when those associations are accessed for them to become loaded automagically.
Our data layer will also be used by a web app so we want this functionality to be added on a layer above our data layer (and thus ignored by our web app).

I've looked at lots of topics on using swing with hibernate although none have really answered my questions.

As I understand it, for an association to be lazy-loaded the thread that is accessing the lazy attribute needs to have a session attached.

One solution then is to keep objects permanently attached to a global session. This is like having a indeterminably long conversation. The problem here seems to be session size - the session keeps hard references to the data objects and thus they will never get garbage collected unless we manually manage flushing of objects from the session. Non-ideal.

Another solution would be as above but to have the session keep weak references to it's objects. Is this possible?

The next solutions avoid the large session/garbage collection problem by detaching objects from the session after hibernate has looked them up :

Another solution is to associate our global session with all threads (and any new thread that get created). Workflow :
We do a query for some objects with lazy loaded associations.
The objects get detached.
We access a lazy loaded association, hibernate gets the session from the thread, loads the association and detaches all the objects.
Repeat
Unfortunately I know no way of associating our global session with all threads - there appears to be no notification of thread construction in the java.

Another solution is when a thread attempts to access an lazy attribute - associate our global session to it. This is similar to above except we associate the session with the thread at a different time - when we lookup attributes. Is there an appropriate point where we could make this call?

Ok, I hope that makes sense. Any help much appreciated.
Tom Hughes

Have you looked in the "Transactional and system architecture design patterns" section of http://www.hibernate.org/36.html? There's lots there to help you.

There is one point I'd like to make about this statement:
I think that's probably the wrong way around. If you decide to go for one of the simpler solutions, rather than say Open Session In View, then you probably should make use of lazy loading as the "normal" data access layer, and use that directly from your swing app. For your webapp, add an extra session layer above the data access layer. That session layer would know enough about the web request to inflate (initialize) all potentially-needed nodes in your hibernate object graph, and leave the rest uninflated. If the session layer has enough info, then you'll almost-eagerly fetch only what you need.

Thanks for your reply but I don't think that resource anwers my question. Essentially I am trying to make use of the fact that I am in a single user, single tier situation (do you count the db as a tier? if so 2-tier). I only need one session but also I want my objects to be garbage collected when no longer used by my app.

Proposed Solution 1: Never detach objects from my global session. Session uses weak references so objects can be reclaimed when not used by my app.

Proposed Solution 2 : Detach objects after lookup. Whenever I access an association ensure reattach my objects.

Are either of these possible or I am I trying to do something Hibernate is not designed for?

I know I am trying to do what it says is asked for monthly in "Why can't Hibernate just load objects on demand?". But in my sitiuation (single-user/single-tier) I believe it's valid.

thanks, Tom Hughes

Yes - this is what I was thinking. Dumb Dao layer, defining the objects and the lazy associations between them. Web Dao layer which knows how much to inflate for web requests. Swing dao layer which allows associations to be automagically inflated on demand.

thanks again,
Tom Hughes

You shouldn't need to worry about when objects get GCed. You can play around with ehcache's maxElementsInMemory if you want, but in the case of a single, very-long-lived session, just let hibernate handle all of that for you.

So sessions don't keep hard references to loaded objects? ie. when my application no longer references an object even though it is attached to a session it will be garbage collected? And of course the flip side - objects wont be dropped or made invalid in any way while my app holds a reference to them?
In this case I can have an indeterminably long conversation and never detach my objects.

I haven't bothered downloading the ehCache source code, so I don't know if it makes use of SoftReference and WeakReference. It does provide that sort of behaviour though. It maintains an LRU list of objects, and will throw away objects when the list grows too long.

If you want to configure the cache yourself, have a look at http://ehcache.sourceforge.net/documentation/#mozTocId258426 for definitions. ehcache.xml goes in the root of your classpath.

objects loaded into a hibernate session will not be gc'ed unless you evict them or close the session.

That makes perfect sense if you belive in getting the same instance when asking for an entity with a given id.

And please think about how you would keep memory usage down in a non-hibernate applicaiton ? here you would also at regular intervals have points where you discard data to not keep it around. Those same places is where you can open/close/clear/evict the session.