[RndTbl] hung mysql transaction locks after a php runtime error?

[Trevor Cordes]

On 2020-07-31 Adam Thompson wrote:
> I think what you need is ErrorException.  See 
> https://www.php.net/manual/en/class.errorexception.php.
> 
> Basically it's a way to turn regular PHP errors into Exceptions so
> you can Catch them, and then you also get to have a Finally block
> where you can rollback unconditionally.
> 
> The comments on that page are more valuable than the official 
> documentation, as usual.

Yes, something like that would be ideal.  I was glancing at it as a
possible solution before, but the bit about not being able to catch
some errors, like E_ERROR or E_PARSE, mean it likely won't help.  Maybe
I'll do a test run to see exactly what error is produced by things like
calling an invalid fn, or calling with the wrong # of args.

Luckily programmer-stupidity mistakes like that are very rare in my
production code :-)  However, they are common on my dev box.  In the
end, if the mysql innodb lock timeout really works as I think it does
(rolling back that thread after 50s) then the repercussions aren't as
bad as I had feared.  A locked-out user for 50s is possibly acceptable.
Locking all users out for 50s is not.

And I have that rollback to start every hit as Scott suggested, so that
should help too.

What I really require is something in the php-fpm engine that lets me
trigger a script to run after every cgi hit is done processing (whether
successful or crashed).  In there I could put a connect/rollback.

Does anyone have any guess what sort of performance hit my site would
take if I turned off all of PHP's mysql connection persistence?  Does
starting a new connection for each hit really take that many cycles?