Documentation update: improve description of .begin(), .commit(), .rollback() idiom

[vic0824]

The usability of the .transaction() method with a lambda is limited by the constraint that a lambda body can only contain references to final or effectively final variables, and this excludes the vast majority of variables defined outside the lambda scope, in a non-trivial application.
As a consequence, it is very common to use the traditional .begin(), .commit(), .rollback() idiom.
It would therefore be useful to improve the description of the .begin(), .commit(), .rollback() idiom in the manual.
In particular, there are circumstances in which the transaction is automatically rolled back by the engine, and in that case the .rollback() method invocation in a catch block will throw a "Transaction not begun" exception.
To handle this scenario, the catch block should contain a check on the transaction status:

} catch (Exception e) {
    if (database.isTransactionActive()) {
        database.rollback();
    }
}

It would also be useful to specify what is the default isolation level, as it is not clear by reading the manual: READ_COMMITTED and REPEATABLE_READ are only mentioned in the chapter that describes the SQL Batch command, so it's not clear if those statements about the isolation level apply to the engine in general or only to the batch functionality.
Furthermore, it would be useful to add an explanation of how to emulate a SERIALIZABLE isolation level, assuming it is possible.

[lvca]

I think we could simplify the usage of database.rollback() by avoiding throwing an exception if the transaction is not active: just ignore it. @gramian do you see any impact with this behaviour?

About the isolation level, we updated the manual in the past months, Check here: https://docs.arcadedb.com/#Transactions.

The default isolation level is READ_COMMITTED.

What's your use case for SERIALIZABLE ?

[gramian]

1. I think I ran into that too once. I guess the change will work. The only thing that comes to mind are SQL Script queries and commands being transactions that fail and could be touched by this?

2. I will look into the docs if the default isolation level is ambiguous, and clarify if needed.

[vic0824]

Yes, the isolation level is now clearly described in the manual.
My use case was n clients all polling the db, looking for a record with a specific value of a property, and when found updating that record.
I have since then re-designed my code so that only one thread polls the database and only one thread modifies it, with an external synchronization preventing simultaneous read/write attempts.