cap-js
fix(REVISIT): Ensure safe rollback and release
Description
When a database connection encounters an error in a query it will trigger the default rollback mechanism. As all queries including rollback are asynchronous it is possible that queries are in progress or in the process of being send. Which can mean that the rollback happens before a parallel query. Which allows the query to escape the transaction. Additionally it is possible to send a query to the database service while it is in the process of rolling back. All new queries to a rollback database transaction should be rejected.
The current approach to prevent poisoned connections from being released back into the pool is to tell the pool to destroy the connection. This does not apply to sqlite, because it does not have the ability to execute two queries at the same time. Therefor this issue cannot happen for sqlite. Additionally if the connection would be destroyed the whole database is reset on the next connection.
Thinking twice about the approach to destroy connections on each rollback, to avoid reusing 'poisoned' dbcs on subsequent requests ('poisened' meaning: dangling operations in a promise chain).
We might frequently rollback transactions due to failed input validations, after some validations read from the database. → in consequence, we would see many transactions destroyed and re-connected (each connect with a cost of ~40ms for HANA).
