BD transactions in Laravel. What is the behavior in different situations?

Question

MySQL

One way to use transactions in Laravel:

DB::beginTransaction();
// великолепный полезный код
DB::commit();

But it's interesting what will happen:
1) For example, if the code does not reach DB::commit();.

DB::beginTransaction();
// начало великолепного и полезного кода
Exeption или упаси бог Fatal Error где-то в процессе
//конец
DB::commit();

(Exeption can you still catch what to do with Fatal Error and what happens after this with the database?)
2) If somewhere in the process DB::beginTransaction() is called again - DB::commit()...

DB::beginTransaction();
// начало великолепного и полезного кода
//вызов восхитительной ф-ции, внутри которой тоже вызывается DB::beginTransaction(), 
//а потом DB::commit()
func(...);
//конец
DB::commit();

2.1) What is the behavior when DB::beginTransaction() is called again?
2.2) If DB::beginTransaction() doesn't change anything, what happens when DB::commit() is called? The entire transaction will fu... end without waiting for DB::commit(), which the ignorant author expects to actually commit the transaction?

3) (similar to 1) If DB::commit(); no one was going to call at all?

PS (For anticipation) I looked at the Laravel documentation on transactions . I found there only how to use it and not a word about the questions that arose.
I know about the (here's) recommended way to use transactions:

DB::beginTransaction();

try {
    DB::insert(...);
    //.....

    DB::commit();
    // all good
} catch (\Exception $e) {
    DB::rollback();
    // something went wrong
}

Interested in exactly how they work when everything went wrong "according to plan" and what consequences can be obtained.

Answer 1

I can’t speak for Laravel (I don’t use it), but most likely these functions call the corresponding database commands (BEGIN / START TRANSACTION / COMMIT etc.). The behavior will, generally speaking, depend on the database.

For example, if the code does not reach DB::commit();.

The transaction will be rolled back (unless, of course, you catch an exception, or, for example, start a new transaction with a successful commit in the same database connection)

If somewhere in the process DB::beginTransaction() is called again - DB::commit()...

It depends on the DB. Mysql, for example, when you re-BEGIN will commit the current transaction and start a new one. Postgres will issue a warning and will not change the state of the transaction.

If DB::commit(); no one was going to call at all?

The transaction will be rolled back when the connection to the database is closed.
Once again - it is written above about the behavior of the database, Laravel may have its own characteristics.

Answer 2

in general, any transaction will be rolled back unless an explicit commit is received.
there are exceptions.
autocommit times. operations that always commit a transaction - two.
smoke mans your subd.
in the case of nested transactions, everything works up to the last branch, except for operations that immediately commit the entire hierarchy of transactions.

Answer 3

Do not use manual transaction level control. The exception is specific situations, where it will be clear that it is needed anyway.
Answering the question, DB::transaction(callable) will rollback the transaction on an exception, the rest of the (manual) control does nothing automatically, except for handling a few specific errors that reset the transaction level themselves.
In general, it’s better not to go into manual control, because it’s VERY easy to get through, it’s difficult to debug, and Lara doesn’t calculate everything.