Part of the answer why R2DBC was created is the need for a non-blocking application stack to handle concurrency with a small number of threads and scale with fewer hardware resources. This need cannot be satisfied with reusing standardized relational database access APIs - namely JDBC – as JDBC is a fully blocking API. Attempts to compensate for blocking behavior with a ThreadPool are limited useful.
- Maybe global transactions - but this increases the complexity of the system and decreases the performance. The underlying resource (database, JMS) has to be able support these types of transactions.
update other system records upon the execution of crud operations of an entirely different (however usually related) record