Hibernate , rich clients and long running sessions
warning : Narrowly focussed techy ( boring ) post
What is a long running session and why is it useful ?
[ This is mostly focussed on using hibernate session in a desktop app but most of it might be applicable to web app too ]
As the name suggests the whole user interaction with the app would consist of one single long living session and all ( main) the communication with the database would be through this session. Your “unit of work” would now encompass all the user interaction with the application …meaning your “application transaction ” ( ref 7 ) is the whole life of the application.
Why ? 1. The Biggest driver for doing this seems to be ablity to use hibernate’s lazyintialization capabilities , for example a dialog displaying Book information can dynamically populate author information when the drop down combo box is selected.
2. Since all the modifications to underlying data is done through this single long running session , you can explicitly demarcate transaction boundries at convinient locations .
3. Take advantage of session cache without having to load/unload object each time from the DB.
If you perform all the major work in GUI thread ( almost all java GUI systems are single event threaded( ref 4 ) you can use tweak thread local pattern to get the main session from a GUI thread .
Above advantages might paint a rosy picture but using long running sessions without much forethought might cause some serious problems that might not really be apparent untill the application get big or complex enough .
- Your app might suffer from ” bloated session cache ” phenomenon..with each your application getting slower and slower with as the session cache grows bigger and bigger as hibernate has to go through all the objects in the session cache for every query ( with huge session this might slow you down ,If the session gets big, flushing it will take more and more time, even if there are no changes). Essentially advantage no 3 above can become a disadvantage ( due to hibernates transactional write-behind ) if session in allowed to grow big. A workaround that might be useful in some cases might be to use query.setReadOnly(true) , session.setReadOnly() for queries/ entities which load up readonly objects into the session.
- Manual “eviction” to keep session consistent, You might have use sql queries for various reasons in various places in the app to perform updates/deletes in such case you have do manual evicts in order to keep session from being corrupted.
- Transactional write-behind might come in your way ( depending on how you manage long running session ) if you plan to access data from “other sessions” .
- User might experience GUI freezing when hibernate is doing its lazyloading magic.
- Classic lazy loading n+1 query problems ( see links below)
- Stale data problems .if the data is updated by some background job or thread not using the main session ..your main session will not be up to date with the changes.
- Hibernate wiki on this topic :http://www.hibernate.org/333.html
- Multi threaded GUI’s , failed computer science dream http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html
- Quick description of hibernate flush modes : http://static.springframework.org/spring/docs/1.1.5/api/org/springframework/orm/hibernate/HibernateAccessor.html
- A very old ( but still relavent) blog on hibernate team blog http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/01/27
Filed under: Uncategorized | 1 Comment