Cache DB connection for 30 minutes and reduce timeout

[Rixxan]

In GitLab by @rik079 on Apr 22, 2021, 08:02

I don't think there's anything wrong with storing and reusing a connection for a short while, as long as it's not, well, 8 hours. So 30 minutes seems reasonable. This would also speed up a significant number of functions and commands. We would still need to check if the connection is still there whenever we request it, and handle events where we disconnect while it's cached excactly as if a new connection is requested every time. It goes without saying that there should be an option to request a new connection anyway.

One thing I've noticed about DB connections is that they're established really-really-ridiculously fast. This makes sense as both run on the same box. This makes it, as far as I'm concerned, reasonable to assume that if we can't get a connection in 0.5 seconds, we can't get it in 10. Because connecting is a blocking action and no other commands can be executed in what can be up to 30 seconds if we're switching to Offline Mode, I'm proposing that the production DB timeout be reduced to 0.5 seconds. In a worst case scenario, we only block the event loop for 1.5 seconds.

This would of course need some experimentation so we can make sure that a connection is always achieved within 0.5 seconds, but we still would have plenty of room to adjust that number.

[Rixxan]

In GitLab by @rik079 on Sep 28, 2021, 09:48

I had a go at this a couple weeks ago but after having dived into a learning module about the __new__ method today I realise I probably got it wrong back then, and more importantly what I did wrong. Going to try again somewhere this week

[Rixxan]

unassigned @Rixxan

[Rixxan]

Delaying this until 2.0 in the interests of time.

[Rixxan]

marked this issue as related to #142