“The bottom line™” of that post, of course, being:   Not a bug. Using a connection from more than one thread is not allowed.

I hope that your notion of “create 5,000 threads” was just a hypothetical experiment.   Or perhaps a “worst-case load” test.

Surely it was not something that you really contemplated doing ...

On the assumption that this surely must (not) be your intention, let me make a parenthetical comment. . . not addressed to “you.”

I shudder at the number of well-intentioned programmers who imagine that “creating hundreds or thousands of threads” multiplies the computer’s time, instead of doing what it actually does; namely, “chop the computer’s time into useless confetti and then shove that confetti up the poor computer's :-O.”   (Ahem...)

It also matters to consider what is happening over on the server side.   The server is being pounded with requests coming against a single table ... and, let’s face it, only a very few of those requests can be serviced at one time because they will naturally contend with one another for use of the common resource ... the table, and a rapidly spinning piece of metal.   All of the rest is just “plugging up the system.”

All of us in computer school learned about “thrashing.”   Well, server programs can “thrash” in a great many ways, not just those related to virtual memory (or the lack thereof).   Any accumulation of detrius, beyond the server program’s actual capacity to handle it, causes throughput rates to plummet. And, as with classic virtual-memory thrashing, the decline is exponential, not linear.   (So, the result is not merely “bad.”   It is catastrophic.)   Even if the host computer is busy-as-a-bee and with no excessive paging at all, a server program can be, well, constipated!   We have demanded that it do what it physically cannot, and (in the case of a great many servers) it “dies, trying.”

This point was hammered-home to me early, when our school’s engineering department was teaching students using an expensive and resource-hungry program on a too-small (mainframe) computer.   The students all tried to run the program at their terminals:   the computer all but dropped dead, finishing the jobs (if at all) in as long as eleven hours.   (But if no one else was using it, the runs completed in about two minutes.)   The little light went on.   I arranged things so that all of the runs were done in batch mode, and I dedicated a special batch queue to those jobs, with adequate resources to run the program and a queue-limit of three, having calculated that the computer could reliably complete jobs in about four minutes each at that MPL.   “This queue,” I assured them, “is exclusively yours.”   Even if 30 students submitted their jobs at exactly the same instant (and of course, they never would), I could guarantee that they would all get their results in less than an hour.   Typically throughout the semester it was about five minutes.   (I checked.)

Less ... is more.

Don’t guess ... measure it.   When in doubt, stick a meter on it.