Why don't major database providers provide truly asynchronous APIs?

I work with Oracle and Mysql, and I try to understand why the APIs are not written so that I can call, leave and do something else, and then come back and pick it up later, for example, NIO - I forcibly devote the thread to waiting for data. It seems that SQL interfaces are the only place where IO synchronization is still forced, which means binding a thread waiting for DB.

Can someone explain the reasons for this? Is there something fundamental that makes this difficult?

It would be great to be able to use 1-2 threads to manage my database query problem and retrieve the result, rather than use worker threads to retrieve data.

I note that there are two experimental attempts (for example: adbcj) when implementing the asynchronous API, but none of them are ready for use in Production.

+5
source share
2 answers

Database servers must be able to handle thousands of clients. To provide an asynchronous interface, the database server will need to store the result set from the query in memory so that you can pick it up at a later stage. He will quickly become out of resources.

+1
source

A significant problem with async is that many libraries use threadlocal for transactions.

For example, in Java, most JDBC specifications use synchronous behavior to achieve a single thread per transaction. That is, you write the transaction in a procedural manner.

, . node.js, , , .

, async, , , , , , .

(Java): jdbc?

, , ​​ RabbitMQ.

+1

All Articles