Dealing properly with connection timeouts, &c.
kgaughan opened this issue · comments
One thing I haven't thought about properly yet are cases where, and this is particularly pertinent when it comes to connection pools, is what happens when a connection times out. Having it deal with that properly is critical to getting it properly battle-hardened.
The reason I haven't dealt with this is that DB-API's OperationalError exception is a touch vague. I've a nagging worry that discarding a connection based on catching that alone might not be an altogether excellent idea. It may be the safest one though.
All that aside, dealing this this particular issue has two aspects: the single-connection aspect and the connection pool aspect. For single connections, the connection mediator will need to be able to reconnect at will to the DB. For connection pools, the mediator will need to have some way to signal to the pool that the connection it currently holds is somehow bad. In both cases, the context will have to signal to the mediator that the current connection is bad.
The best place to handle the error is in the __exit__ method of the mediator. That way the context doesn't have to explicitly signal to the mediator that the connection's bad. SingleConnectionMediator will need to be tweaked so that it takes a function that returns a connection rather than be supplied with an actual connection. This would make its behaviour a touch more consistent with PooledConnectionMediator. It'll also have to start counting depth so its behaviour is consistent regardless of whether it's used within or without a transaction.
Well, I now know it works just fine at least in the single-connection case. That's good. Now I just need to write something to exercise connection pooling.
The connection pool handles this properly, unless I've totally messed up and just don't realise it yet.