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?