Add Server OPTION to Disable Implicit Commits, do Rollback and Fail instead

Add a SERVER level config option such as:

FORBID_IMPLICIT_COMMIT = 1;

that when enabled, prevents MySQL from performing an implicit commit.

If auto commit is disabled, and a statement that would cause an implicit commit is run, instead of executing the implicit commit, first check if FORBID_IMPLICIT_COMMIT is enabled, and if it is, do a ROLLBACK and fail instead of doing the commit.

i.e.
START TRANSACTION
select 1;
update mytable set x = 1;
drop table if exists othertable;
( the "drop table" command never executes, TRANSACTION rollback is triggered )
( SQLException is raised and does NOT wait for the rollback to apply before returning the errors to the client )
The 10 other statements that should have run after the "Drop table" command but before the COMMIT command are never run

Errors and bad/inconsistent data due to Implicit commits are some of the MOST difficult code to track down and fix. Particularly because of call chains/nesting. If you simply forget to include the "temporary" keyword in your drop/create statement, boom, you've accidentally commited your transaction, and if anything after that command fails, it won't be rolled back as you expect.

We've encountered this issue enough times with painful effects from it that we have a monthly rotation amongst all the developers to do code scans for common code that would trigger implicit commits and trace them to make sure that an implicit commit shouldn't occur.

Despite being pretty disciplined, we still catch code from time to time that causes implicit commits. The time spent finding code that does NOT intend to perform commits is costly, as is fixing any data that is a victim of an implicit commit that couldn't be rolled back.

It seems like having the DB server OPTIONALLY perform this check for us wouldn't add much overhead and would provide incredible value.

I've seen this feature shot down on the MySQL bug tracker because "It handles implicit commits the same way OracXX" does and "we think that's the right way". But that's the worst justification I've ever heard to dismiss a valuable feature. If something provides value, is backward compatible, and is achievable; then why not progress the software further and provide the feature? Otherwise you're just an OracXX wannabee. OracXX should want this feature and should be jealous of Maria for having it!

I'm hoping the minds behind MariaDB are more pragmmatic and open minded!