I agree with Ron. If connection is broken between 4 and 5, I would expect the transaction to be rollback (it was not commited), and an error raised. Probably that request will fail, but at least the connection is not dropped and not recoverable.
I guess in a server restart or shutdown, the server will probably (or should) wait until active connections are finished, and stop accepting new connections meanwhile. So the problem is likely to happen when there are idle connections in the pool, and the server is restarted. The connnections in the pool are invalid and can't be used anymore, but they won't recover, as web2py won't notice they are disconnected... Greets. On 15 jun, 17:28, ron_m <[email protected]> wrote: > Unless step 6 is reached and completed if the client closed then I would > expect the database server to detect the closed connection and rollback on > its own since there is no way to recover the state built on that connection > or if the database server is restarted then the database server should > perform startup recovery and rollback anything that isn't completed but the > client still needs to clean up. > > What this smells like is a connection pool will hold open connections for > reuse, the database server is restarted because of a maintenance script and > now the pool has stale connections. When one of these pooled connections is > given to a user task the connection should be detected as stale in the pool > logic and a reconnect attempted before handing it over to the user. > > What Alvaro describes is similar but it looks like the DAL won't initiate a > new connection after a server restart unless a ping is performed. Is it > possible there is state being held in the DAL or the mysqldb driver that > says there is a connection but is not cleared to allow an attempt to get a > fresh open on the database?
