HAR Deployer: Why is AUTO_CLOSE_SESSION hard-coded as TRUE ?
I would like to use the following pattern for my web application:
(1) A new HTTP request comes in and is intercepted by a ServletFilter that starts a new hibernate session for the current thread (using ThreadLocal).
(2) The request gets passed on to Struts and some actions that work with my data and may call several independant transactions to update the data. No Session EJBs are involved.
(3) The request is then passed to some view mechanism (JSP or XSLT, etc.) that may use Hibernate objects that were created or loaded earlier.
(4) At the very end, the request passes through the ServletFilter from (1) again, where the Hibernate session is gracefully closed.
When using the JBoss HAR Deployer, the session factory is configured with FLUSH_BEFORE_COMPLETION="true", AUTO_CLOSE_SESSION="true" and RELEASE_CONNECTIONS="true". This causes the session to be flushed and closed as soon as I commit the first transaction in my code (Transaction.commit()) and the view mechanism will throw exceptions: lazy-initialization for my objects fails, because the session they were attached to had been closed, or the objects were no longer attached to a session, respectively. I'd like to avoid calls to session.refresh() or lock() and would rather keep one session open for the whole request.
Looking at the source code of /org/jboss/hibernate/jmx/Hibernate.java shows, that the AUTO_CLOSE_SESSION is hard-coded to "true" in the getProperties() method there. If I put a hibernate.properties file into my HAR, the log file shows that it loads my settings at first (yaaay!), but overrides them with the hard-coded ones later (bummer!), right before the SessionFactory is created..
While doing some research, I came across a posting by Steve Ebersole at http://jira.jboss.com/jira/browse/JBAS-1828, where he writes:
[...] Do not use the HAR deployer and continue to use HibernateUtil for session management. This is because of the fact that HAR deployer automatically enables auto-flush. This obviously could be made configurable, but I am not convinced that is the right approach. You can try to convince me ;)
The HAR Deployer works perfectly for me, except for this one little thing. Can someone please explain to me what is so terribly wrong with this approach?
Bernd.
PS: I tried to patch the Hibernate.java file mentioned above by commenting out the hard-coded values; then it accepts my settings from my hibernate.properties file and works just as desired. But is there any danger disabling AUTO_CLOSE_SESSION?