No, most databases don't support nested transactions, but many provide savepoints which allow roughly equivalent functionality. PostgreSQL and MySQL do; even recent releases of SQLite. Indeed, so does Microsoft SQL Server.

So if you want to write decent cross-database code, use savepoints instead of nesting transactions. Of course, as is often the case in SQL land, syntax for establishing a savepoint, rolling back to a savepoint, or releasing (kinda like committing) a savepoint vary from database to database. But not too badly.

Your code, as I understand it, when it wants a nested transaction, opens a new database connection, runs the nested transaction there, and holds the transaction open until it's sure the outer transaction is ready to commit. It's a reasonable solution in the case where you're on a database that does transactions but not savepoints.

However, I think it probably has some flaws. You'd typically want code running in an inner transaction to be able to "see" database changes already made in the outer transaction. But if your database is doing ACID properly, then an independent transaction on a second database connection will not be able to see the changes made in the initial transaction until that initial transaction has been committed.

Nested transactions do indeed have some advantages over savepoints. Savepoints need to be given names. That means that Perl code that is executing an SQL transaction, and calling other Perl modules to execute inner transactions, needs some co-ordination between modules to ensure that savepoint names are unique. Nested transactions are anonymous so don't have this problem.