In my application I am intending on having multiple SessionFactories to various databases on the network.

I am using the Spring Framework and a Context Listener within Tomcat to start these sessionFactories when the Servlet loads.

It is my understanding that when the Servlet starts, the Spring framework will initiate the database connections for the session factory. These connections are held open for the life of the Servlet--basically when you start and stop the Servlet through the Tomcat Manager or start/stop the Tomcat server.

Here's the scenerio: Everything starts up correctly, ie: Spring was able to create all the sessionFactory objects and connect to the databases. Some time passes and there is a network problem and database connectivity is lost. When a user attemts to utilize the web application, an exception will probably be thrown which I will catch in my DAO layer.

I'm assuming that there is a way to reconnect to the data source and if so, from which object would I perform that function?

My plan would be to attempt one reconnect to the data source, if that failed, pop up an error message to the user to try again later...

So the tricky thing is that somewhere I'll need to reconnect to the database for the sessionfactory, is this possible?

Please keep in mind that I'm a newbie when it comes to Design Patterns and pattern-based object oriented java developement. I get the multi-layered concepts of your Business Object -> DAO -> Database, but I'm no master....

Thanks,
Mark

There's a misunderstanding here: A SessionFactory will not hold database connections on startup. Rather, each Session will fetch a connection from an underlying JDBC connection pool on opening, returning it to the pool on closing. You don't need to reconnect the SessionFactory at any time: It will automatically fetch fresh connections from the pool for each new Session.

So the problem of holding open connections is purely an issue of the JDBC connection pools, just like with plain JDBC. In a typical Spring app, JDBC DataSources will serve as pools, either locally defined or fetched from JNDI. Each LocalSessionFactoryBean receives a reference to its DataSource via the "dataSource" bean property. From the DAO point of view, you should assume that a pool always returns valid connections.

To deal with database outages, you'd need to use a reliable JDBC connection pool, possibly issuing validation queries before it returns a connection to the application. With proper pool configuration, the pool should automatically retry if a connection is dead, throwing an exception only if the retry failed too. You should not need to do that in your DAOs, neither with plain JDBC nor with Hibernate.

If you're running in an app server, try to configure the container DataSources accordingly, linking them into a Spring application context via JndiObjectFactoryBeans. Else, you could use Jakarta's Commons DBCP 1.1, or C3PO for local DataSource definitions. In any case, do your own tests with a couple of pools, and never trust the feature lists :-)

Juergen

I just noticed that you're running on Tomcat. In this case, JNDI DataSources won't make any real difference, as they will be Commons DBCP 1.0 ones. So I suggest to take a look at locally defined connection pools like Commons DBCP 1.1 or C3PO.

BTW, I assume you're using Spring's ContextLoaderListener to load a root application context at startup, defining various LocalSessionFactoryBeans for your DAOs in there? At least that would be what I recommend.

Juergen[/list]

Ahhhhh... (lightbulb goes on)

Ok. For whatever reason, as I've been learning both Hibernate and the SpringFramework at the same time, I assumed that the SessionFactory was holding database connections open.

Inside my applicationContext.xml file I'm using org.springframework.jdbc.datasource.DriverManagerDataSource as the dataSource to wire into the Spring LocalSessionFactoryBean. I was assuming, for some reason, that when the ContextLoaderListener was called from within the Tomcat web.xml, a database connection was opened. I see that this was wrong.

By using the DriverManagerDataSource, my application behaves just like I'd coded previously without Spring or Hibernate:

User clicks "Post" on the website
Application opens database connection
prepares and executes query
closes connection
returns data to webbrowser

For Spring managed Hibernate Sessions the process would essentially be the same unless, like you've said, you use JNDI.

For right now I'm probably not going to require the use of the Commons Database Pooling, but eventually I will... First I need to get things working, then I'll worry about performance. It's just outstanding that I can wire it into the framework at any time. Very slick.

Thanks for your reply,
Mark