I can reliably reproduce the bug in our environment, but unfortunately now that we know how to fix it I can not justify taking the time to create a reproduction script that will run anywhere.
The server is mariadb105-server-10.5.23. I do not believe the version of the server matters.
The mysql client is perl code using p5-DBD-mysql4-4.052 in a PerlHandler from ap24-mod_perl2-2.0.12,3 under apache24-2.4.58_1.
The way our perl code is structured is we have memoized objects representing conferences. There is a perl class (package) variable hashref where the keys are object IDs and the values are pointers to perl objects. When calling the ->new() method, if the hash has a pointer to the given ID already, we just pass that back rather than initializing a new object. An object initializes a database connection which stays as a property of the object.
Under mod_perl, each Apache prefork MPM worker process has its own perl global memory space. Therefore the second time a given worker thread wants an object of a particular ID, it will retrieve it from the class memoizing hashref.
The first time a client hits the URL on a particular Apache prefork MPM worker thread, the object and the database connection are created and saved in the memoize hash. Our test server has 4 worker threads so we almost always see the problem on the 5th hit. The second time a clients hits a URL that asks for the same conference object on the same worker thread, it retrieves the object from the hashref.
When the code then tries to re-use the old database connection, we see errors like “Statement not active” . Inspecting the database handle, we can see that there is a thread_id that is the same as what was used before for this memoized object, but the mysql_hostinfo property is empty.
What changed between p5-DBD-mysql version 4.050 and p5-DBD-mysql4 version 4.052 ? My guess is something about how the DBI handle object is closed. I think before, the $dbh handle was completely deleted when the handler exited, whereas now the handle sticks around even after the database connection has been closed.
Is this really a bug the maintainers of those perl modules should care about? I do not know if it is reproducible in any environment other than a mod_perl handler, and some might consider that a perl coder who re-uses data between handler invocations under mod_perl may be expected to get what they deserve.