I'm doing a lot with mysql innodb transactions in php these days.
I'm wondering, if I start a transaction and use "FOR UPDATE" to lock a bunch of rows (or maybe more critically, the "next auto-insert row"), and then PHP hits a runtime error (say a call to non-existant function), will something in php or mysql (or probably more precisely php's mysqli library) rollback my transaction?
Or will my transaction locks stay in place until the next user of that php-fpm thread calls "rollback" or "start transaction"? ... possibly hanging a subsequent web hit if they need the locked rows! (Yes, innodb_lock_wait_timeout in mysql will eventually clear things up, but I'm using the default of 50 to be safe, and I don't want an end user UX to wait 50s for a page load!)
I'm using php's default mysqli persistence options, so the connection, while not "pooled", does persist across web page hits (for performance reasons).
I'm guessing if I turned off all mysql persistence in php that mysql itself would rollback when it senses the lost connection. However, I'm not sure how much performance I'll lose if php can't use connection persistence?
I assume this problem would also exist for other db engines and other hit-based web languages (with persistence).
Maybe it's late, but I'm having a hard time coming up with test case that proves what is going on one way or another. However, I could swear that I've already hit the problem and had web hits hang until restarting mysql. In the meantime I'm putting a "rollback" call in my mysql connect function so after (re)connecting to a persistence connection it'll rollback any previous-errored-out-hit leftover garbage. However, with many fpm threads/ps's who knows if the errored-out thread will get a new hit right away!