I've never used Spring before, but, I'm guessing that it does the same as this, which is how I'm doing it. Using a filter like this works great IMHO.

http://hibernate.org/43.html

Jon

----- Original Message ----- From: "Neal Haggard" <[EMAIL PROTECTED]>
To: "MyFaces Discussion" <myfaces-user@incubator.apache.org>
Sent: Friday, April 08, 2005 3:16 PM
Subject: RE: Where to store DB connection in JSF session



Aaron,

We are using the SpringFramework to help with a lot of stuff like this. We have installed a servlet filter that starts the hibernate session at the beginning of the request and ends it at the end of the request. This has been a huge boon for us in allowing lazy loading of our objects.

   <filter>
     <filter-name>hibernateFilter</filter-name>
     <filter-class>
     org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
     </filter-class>
   </filter>

   <filter-mapping>
     <filter-name>hibernateFilter</filter-name>
     <url-pattern>/*</url-pattern>
   </filter-mapping>

There are a good number of other benefits to integrating in Spring with JSF and Hibernate. It uses a very similar idea of dependency injection, and provides a JSF Variable Resolver that will look within the Spring managed beans when looking for beans via JSF EL. We have all of our Hibernate/Database configuration managed by Spring.

-----Original Message-----
From: Aaron Bartell [mailto:[EMAIL PROTECTED]
Sent: Friday, April 08, 2005 3:11 PM
To: MyFaces Discussion
Subject: Where to store DB connection in JSF session

Up to today I have been storing my Hibernate db connection in a session bean called DBConn, but I am finding that it is timing out quite often even though I have database connection pooling setup through Tomcat JNDI (using MySQL as DB).

What I am wondering is what practices others use in storing their DB connection in JSF apps. My thought is to grab a new connection at each request vs trying to store it in the FacesContext. I was going to do this by utilizing phase listeners - open my Hibernate session in the "Restore View" phase and close the session in the "Render Response"
phase. This way there is no way I will ever get a timed out DB connection is what I am thinking.


What are other's thoughts on this, and what are others doing for a scalable DB connection mechanism?

TIA,
Aaron Bartell




Reply via email to