Informing the users is not a problem in our case because it's our internal app that is used by our employees during business hours and we reboot the database server on weekend. The only problem is that without restarting web2py people get the above error once they start using the app on Monday. Looks like the only solution to this right now is to schedule web2py restart right after db server reboot. Not ideal, but should work for our weekly updates. This will still be a problem in case of intermittent network glitches or if db server goes down unexpectedly which may result in unusable connections in the pool. Ideally web2py should be able to recover without restarting. While it obviously cannot do anything while db is down it should be able to start working again once the db is back up. I think ADO.Net pooling works this way (at least we never had the above problem in .Net apps).
-Roman On Mon, Jun 27, 2011 at 1:49 PM, Massimo Di Pierro < [email protected]> wrote: > Yes this is because of connection pooling. The fact is, when you > database is down, web2py will return errors because it cannot connect > to your database. While on the one side we could have web2py return > more graceful errors, I think it is better follow the following > strategy: > > 1) redirect all your http requests to a static pages that says "down > for maintenance" > 2) turn off web2py (reboot the server if using apache for example) > 3) turn off database and do required database maintenance > 4) restart database > 5) restart web2py > 6) redirect http requests back to web2py > > I guess web2py could handle the missing database connections itself > but you still are left with the problem of informing the users. > > > On Jun 27, 12:06 pm, Roman Bataev <[email protected]> wrote: > > We run web2py with ms sql server as a database backend. Every weekend sql > > server gets rebooted (to install microsoft updates), after which web2py > apps > > start failing with the following error message: > > > > *('08S02', '[08S02] [Microsoft][SQL Server Native Client 10.0]SMux > Provider: > > Physical connection is not usable [xFFFFFFFF]. (-1) (SQLExecDirectW); > > [08S02] [Microsoft][SQL Server Native Client 10.0]Unable to open a > logical > > session (-1)')* > > > > The only way to get them back up and running is to restart web2py. > > > > I suspect it has something to do with database connection pooling (which > we > > do use). I have not taken a look at the code yet, so I am not sure if > web2py > > connection pooling reopens physical db connection if it becomes unusable > > because of db server reboot or network failure or something else. > > > > Has anyone had this issue? I cannot think of any good solution for this > so > > any help would be highly appreciated.
