What is the preferred way to deal with timeouts on the session's database connection? We are using NHibernate with ASP and occasionally due to an overloaded server or large set of inserts/updates set flushed, the database connection may timeout. I'm not convinced that simply setting the timeout on the db connection to some arbitrarily large value for certain pages or for all of our NHibernate sessions is an appropriate solution.

Has anyone tried catching timeout exceptions, so that the user can be prompted if they want to resubmit with a longer timeout? that would be best in my opinion, since then the default timeout can be kept reasonable, and the user has a choice if the query or flush isn't returning in a reasonable amount of time.

Dont ask the user a question like this. They are not equipped to give an informed answer.

How could it hurt? By not handling the timeout, their request to save data is lost -- they have to re-enter everything. One of my co-workers claims that when he gets a timeout from an ASP page trying to save data with NHibernate, the browser is hosed and he has to close it and open a new one. I don't know if this is caused by how we're using NHibernate or not, but it's certainly not acceptable, and making the timeout huge doesn't sound acceptable either.

If it's possible to catch a timeout exception and resubmit the data without losing it, even the stupidest user can't screw up a prompt like this:

The server has not responded to your request to save data in X seconds. The server may be down, there may be a network problem, the server may be very busy, or your request may require more time. Try again, waiting 2x seconds?

If they cancel, it's no worse than hitting the timeout in the first place. If they retry and it works, they haven't lost their data. In neither case do they sit there waiting forever if you attempt a band-aid solution with a long timeout, wondering if it's a network problem or if it's really taking that long to process. The initial request isn't still pending when you get the timeout, so you can't accidentally get the request successfully processed twice if you retry.

Why not solve the problem instead of hacking around it? I have never used a web application that asked me such a question, and I would lose a lot of confidence in one that did.

Timeouts are not normal... you should not treat them as part of your normal business process.

I'm not thrilled with having to deal with short timeouts, but due to the political situation at my employer, I have no choice. (I could quit, and I'm thinking about it, but in the next several days that's not an option for me ...) They simply want to crank up the timeout to something large, to "make the problem go away". Since we are creating an ASP/NHibernate development framework for customers to use, and have no control over the quality or settings of their database server, my task is to bump up the timout on the database connection.

Unfortunately, IDbConnection.ConnectionTimeout is readonly. In our non-NHibernate client/server product, it is manipulated via IDbCommand.CommandTimeout. How can I get access to this with NHibernate?

Looks like we can set hibernate.command_timeout in the config file, or set NHibernate.Cfg.Envrionment[NHibernate.Cfg.Environment.CommandTimeout] in code.

Cool, thanks for the info