Julien Goux
03/16/2022, 4:04 PMJulien Goux
03/16/2022, 4:09 PMJulien Goux
03/16/2022, 4:09 PMJulien Goux
03/16/2022, 4:09 PMdpetrick
03/16/2022, 4:15 PMJulien Goux
03/16/2022, 4:38 PMJulien Goux
03/16/2022, 4:38 PMJulien Goux
03/16/2022, 4:38 PMdpetrick
03/16/2022, 4:43 PMdpetrick
03/16/2022, 4:43 PMdpetrick
03/16/2022, 4:44 PMJulien Goux
03/17/2022, 8:23 AMdpetrick
03/17/2022, 11:42 AMwhat’s the point of dropping + recreating the connection in one go? Shouldn’t connections be freed if not used after some time?This directly relates to my previous message, it's about circumventing platform issues where databases kill connections after a given time, which would lead to intermittent issues if the pool hits a connection like that. The current pool does no asynchronous housekeeping, which is why everything is lazily evaluated when a connection is touched.
If we set a max_connections at something like 10, will prisma eagerly open 10 connections and maintain those 10 connections all the time?The pool is not eagerly filled, only with more requests coming in will the pool increase in size until max is hit.
Shouldn’t connections be freed if not used after some time?We have internal back and forth discussions about this. I can't disclose more right now, but we're actively discussion the pooling situation.