I've been reviewing session management strategies in an effort choose the correct one.

I've got a thick-client app talking directly to a database. In an effort to keep my UI responsive, I spawn background threads to load and save data to/from the database. I've been using an 'open session->load/save objects->close session' model, and am suffering (performance-wise) as a result.

Since this is a single-user application, I'm concidering a singleton session, synchronized to make it threadsafe. However, it seems that perhaps I should use the TLS pattern, but I'm concerned about having objects loaded by different sessions, should two database io threads happen to run concurrently.

Is there a standard pattern for such a (client/server) application? I've seen lots of discussion regarding N-Tier applications and TLS.

I did this wrong once, I just want to make sure I get it right this time, so any help would be greatly appreciated.

I think the thread-local session is mostly used for Web applications.

This is a good article on the length of a session:
http://hibernate.bluemars.net/168.html

Pay attention to the "application transaction" explanation. It's a good rule of thumb for the length that you keep a session around.

Good luck!
Jenica

I think you do not need ThreadLocal if you start thread yourself.
Use base class for all threads:

public abstract class BaseRunnable implements Runnable{

private Session session;

public fianal void run(){

try{

doRun();

}fianally{

commitAndClose();
}

}

/**
* All threads in application must implement this method (abstract method),
* "getSession" must be used to open session,
* It is application error to commit or close session session in this method, base class doe's it in "run" (final method)
*/

protected abstract void doRun();

/*
* it can return wrapper to make sure close/commit throws exception,
* detect broken contract.
*/
protected Session getSession(){
if(session == null){
session = openSession();
}
return session ;

}


}

Thick client apps are allways a bit of a pain, particulary because it is really not easy to figure out where one "buisness transaction" starts and ends. One important thing to remember is, Sessions are not thread safe. So a singleton session is not a good approach if you are working with multiple threads.

IMHO the approach you have been using is not that bad, why do you loose so much performance? Sessions are really lightweight so constructing them should not be that bad ...

If you use a ThreadLocal Session for your data access threads, you will pretty much get the same pattern, or are your Threads doing lots of open/save/close cycles?

I described the symptoms I was experiencing in a recent posting:

http://forum.hibernate.org/viewtopic.php?t=928208

The response was that my session management strategy (i.e. open/read/close) was the source of my redundant data problem.

In a single-user, thick-client application, it seems that a synchronized, singleton session pattern might be the best approach.

I don't think so - if you have an exception then the session becomes invalid. You then have to manage this situation before another transaction can be started. Its easier to throw it away (after the rollback). It best to use boundaries that represent the unit-of-work. In most cases these are represented by an event handler. In the case of spawning threads to do the background work then TLS pattern is the best approach (but swing itself is not thread safe so you have more then hibernate's session object to worry about here).

I'm certainly not opposed to using the TLS pattern. My interest is in using the 'correct' session management pattern, whatever that may be.

Perhaps you can help me to understand how TLS might support lazy loading in the following circumstance:

The user opens/displays a 'view' that provides for navigation of complex object graphs stored in the database. A background thread is spawned to load the object graphs. If I dispose of the session object when the loader thread is done, then I lose the benefit of lazy loading during object navigation within the view.

This is the primary issue I set out to resolve. However, I'm also concerned about the following situation:

The user modifies portions of the object graph and clicks [Save]. Now, a new background thread, with it's new session object will be required to persist an object graph loaded by a different session object. My concern is that this will lead to inefficient updates.

Thanks again for responding.
-Mitch

Using TLS in your case is useless.
sharing session between different threads sucks unless you synchronize it.

I you can't/don't want to synchronize, you should consider using a second-level cache to fit your needs.
To avoid extra updates, consider using version checking or dirty optimistic-lock. You'll have an extra read, but It may not matter in your case (graph update).

Hi!

I'm also thinking about a think client application which will operate directly with the business logic layer to read, update and create data.

Although the persitence handling should be covered by the business layer isn't it possible to delegate the session management to some kind of system layer where the display and interaction layer ('view') must obtain a session for accessing the business layer?

This way every view (dialog, wizard...) has its own sessions and I'm able to keep a session long enough open while lazy loading is performed.

Is this approach acceptable?

Thanks,
Gunnar

Beware stale datas

Does it mean the cache of a session is not updated when updates are performed in a transaction within another session in the same VM (I don't want to ask about clustering)?

hibernate sessions are independant, think session as "business unit" cache, if you use a second level cache, all hibernate sessions will work with the second level cache, i think this is the best solution for you: TLS + second level cache (ehcache is easy to use)

Hi,

I read many (if not all) the forum posts regarding lazy loading in thick clients and session strategies / session synchronization. I think I understood why the session is not threadsafe, why synchronizing on the session is usually not considered good practice and why the DB should cope with concurrency etc. Nevertheless, I think I have a case where the "easiest" solution would be to fully synchronize on the session. The problem here is synchronizing the use of the session for lazy loading of collections.

My single-user Swing app uses a tree to view an object graph. Loading the complete graph at once takes much too long (I tried it), so I declare all collections as lazy. When the user expands a node, the tree spawns an extra thread to load the data. My session strategy is best described as "session-per-application-transaction". Basically, I use a new session whenever a new object graph is loaded into the tree. The session stays open, allowing for transparent lazy loading. The user may also edit individual objects from the graph. On clicking [save] I flush and commit the current session from within a thread spawned by our GUI framework when clicking a button.

Problem:
Flush() and commit() happen in a different thread from the lazy loading. Most of the time everything works fine but from time to time I get error messages from Hibernate like the ones shown below. I synchronize all explicit session operations (flush etc.) but I don't know how to synchronize lazy loading on the session object. I read http://forum.hibernate.org/viewtopic.php?t=925435 and agree with all advice given there, but I think my situation is different.

Is it possible to have lazy initialization synchronize on the session held by the lazy collections? Thanks for any kind of help.

Kay

I use Hibernate 2.1.2.

Here's error message 1:


And error message 2:

My session synchronization strategy was a bit more inclusive.

I serialize access to a singleton Session object through the use of a HibernateSession.getCurrent() method (HibernateSession is my own implmementation of the singleton pattern). This method guarantees single-threaded access to the (singleton) Session object (using Session.wait()/Session.notify() semantics).

A thread uses the session in the following manner:

o Access the Session object via HibernateSession.getCurrent()
o Interact with the Session object as necessary.
o Release the Session object via HibernateSession.release()

If a thread is currently using the Session object, any subsequent calls to HibernateSession.getCurrent() will block. As soon as the owning thread releases the Session object (via HibernateSession.release()), one of the waiting threads will be awakened and granted access to the Session object.

FWIW, I have not had time to fully test this model. I have implemented the code and the prelimary tests look promising. I haven't seen any exceptions as yet. Your your mileage may vary.

But what about lazy initialization? As far as I understand, Hibernate's lazy collections carry around a reference to the Session they were created under and use it to transparently retrieve data from the DB when the collection is accessed. I don't know how I can force the use of HibernateSession.getCurrent() (or my equivalent) inside Hibernate's lazy initialization mechanism.

I think I need a Hibernate option "synchronize on Session object when doing lazy initialization". Hm, I can imagine Gavin's reaction on this suggestion :-)


I'm curious if you experience any errors similar to mine when you start to use your model extensively.