so from my point of view, CUBA is blocking in all of the above mentioned parts. But i might be wrong on that. So if anyone with more insights on that topic see’s that im writing bullshit here, don’t hesitate to correct me
Let’s begin with the database access part. The problem with this in the Java space is that JDBC itself is blocking. This means that all ORMs will not be really be capable of asynchronous database calls. See this SO thread for more information. There are exceptions like for Postgres there is a async driver, but these are not based on JDBC. In the NoSQL world there are more examples of async like the async mongo db driver. When you look at the recent blog post about the future of spring data, you’ll see reactive examples (but all for non JDBC). So therefore this is quite a hard sell. I think there is much buzz around it especially in the java world.
Since CUBA uses JPA as a ORM (which is based on JDBC), therefore the database access is blocking (with the normal thread pool model).
For HTTP requests i think we have to differentiate between the generic UI and the REST API as well as the Portal module. I know that for generic UI it’s based on Vaadin which uses atmosphere since a few versions. I’m not really aware if the server threads are non-blocking, but i’d assume not.
For the portal module, it is the case that the application developer is allowed to write their own Spring MVC controllers - so we’re are quite near to the metal here Spring MVC has async support since quite some time, since the servlet spec 3.0 is async aware. Here are some more information about this topic.
So this we’re my two cents on that. I hope this helps