Hi,

So I'm wondering if there is any way to allow Hibernate to recover from a database restart without restarting the Tomcat context. When the database is down I get a java.net.SocketException when I try to start a transaction. session.isConnected() and session.isOpen() don't seem to give any useful information. When the database restarts I get the same exception in the same place.

This is a web app running in Tomcat 4.1.x. I'm using a servlet filter to instantiate a SessionFactory and each request gets its own session using the ThreadLocal pattern. I'm using org.apache.commons.dbcp.BasicDataSourceFactory for my JNDI factory.

Thanks

I'm having a problem with this too now. But Hibernate is kicking back a totally bogus stack trace, one has very little connection to the code that is executed.

The problem that I seeing in this particular app is that I am using local configuration objects, not the JBoss service MBean. I cache the SessionFactory calling Config.buildSessionFactory(), but if the database is restarted, it starts blowing these crazy exceptions.

I'm also looking at this from an architectural perspective. Confg.buildSessionFactory() is very expensive. So I can't call it all the time. I wouldn't mind calling it if I could sense when it needed to be called (i.e. after the database connection is lost), but the exception does not happen until session.find() is called. Calling SessionFactory.openSession() succeeds just fine. If the logic required could be wrapped in a SessionFactory facade and the Session that is returned can be validated before it is used by the client, that would not be a problem, and I would welcome a suggestion for a lightweight query or connection validation routine that could be used.

Failing a good way to make sure that the Session that is returned is good, I am going to have to write global exception catcher that knows how to determine that the SessionFactory is stale, then kill the cache so that it is reloaded on the next time through.

I filed http://opensource.atlassian.com/project ... key=HB-592 on this, feel free to close it if I am misguided again :)

I try two isOpen() isConnected()'s together so if it fails the first time I'm able to have DBCP reconnect and catch it the second time. This isn't a problem for me because I use my own facade class so I can have it call a function to return the session (after trying twice, if need be) object or throw an error.

Regards,
David

Well, IMHO it is really the database pools job to validate connections before passing them to Hibernate. There is a setting for c3po which tells the pool to do that: hibernate.c3p0.validate=true. DBCP can be told to validate the connection by setting hibernate.dbcp.testOnBorrow=true and hibernate.dbcp.validationQuery to some SQL query which shoudl succeed allways when the connection is valid.

I am having the same problem as mentioned in this post. I have turned c3po validation on and I still am having connections that are closed when I get them back.

cwidhelm,

can your post more information about this? if hibernate's c3p0.validate is set to true, c3p0 runs a test query against the database and should not hand the connection to the user unless that test query succeeds. if you are seeing broken/and or closed connections when hibernate's c3p0.validate [or c3p0's testConnectionsOnCheckout] is true, something very weird is happening.

what version of c3p0 are you using? if it is the most recent release [c3p0-0.8.4.5], look for a c3p0 configuration dump in your logs when your c3p0 pool starts up, and make sure that testConnectionsOnCheckout is set to true as you expect.

if it is, and you are seeing bad connections, please give me more information about your configuration and the circumstances under which you get the broken connections.

thanks!

steve <swaldman@mchange.com>
c3p0 maintainer

p.s. c3p0's config dump goes to standard error. Find the phrase "Initializing c3p0 pool".

Well, give a shot at proxool (http://proxool.sf.net) - it does a nice job at recovery from database restart - at least in our case.

Make sure you enable the test-before-use so proxool will validate the connection before returning it to you. You should *never* receive closed connections - unless the database is shutdown while you are doing something with the connection... not much we can do in this situation :(

FYI, we currently have a broken dev environment where the database server is regularly unavailable (network failures)... We are using proxool and our application survives without any problem ;)