Currently qbit uses traditional transactions api: begin/act/commit/rollback.

But this such api allows concurrent transactions and requires either keep all transaction data in memory or allow concurrent writes.

Some modern DBs (datomic, voltdb) uses another (stored procedures-like) approach, where user calls code, that is sequentially executed within DB. This approach eliminates concurrency in transaction processing what is especially important in qbit due to kotlin/native memory model.

But this approach make tricky implementing transaction, which requires additional IO (e.g. read some data from DB, execute several http requests basing this data and write results into db).

Consider switch to db-functions transactions API.

Can this API support spring-like approach to transactions - one class upper on stack manages transaction and another classes down on stack works with it?