4 ms·
Ah, ok. Seems clear that this is for a thread requiring C connections simultaneously to get its work done. That would make it a necessary calculation to avoid d
by sudhirj 6y ago
Ah, ok. Seems clear that this is for a thread requiring C connections simultaneously to get its work done. That would make it a necessary calculation to avoid deadlocks. I don't see this being necessary in a Rails type app where there's usually one connection per request, but if one were using Go, setting a max connections parameter, and then simultaneously checking out more than one connections to do work, there's an easy chance of deadlocks.
Will add a section talking about that and this formula.
- twic 6y ago> Seems clear that this is for a thread requiring C connections simultaneously to get its work done. Exactly. As that document says (my emphasis): > The prospect of "pool-locking" has been raised with respect to single actors that acquire many connections. This is largely an application-level issue. Yes, increasing the pool size can alleviate lockups in these scenarios, but we would urge you to examine first what can be done at the application level before enlarging the pool. > Where Tn is the maximum number of threads, and Cm is the maximum number of simultaneous connections held by a single thread. To be honest, i think applications do this are broken ("largely an application-level issue"), so i'm not sure how important it is.