What i do not get: why does one have to use reactive version of db access? I thought one big advantage of virtual threads is that it will detach from the os thread whenever blocking occurs so making it a good choice when dealing with blocking apis as in classic jdbc drivers. Have i got sth wrong?
It does not use a reactive version for the database access. It only uses resteasy reactive, because we have more control on the dispatching strategies. That's something we cannot control with the classic resteasy. In addition resteasy reactive has a lot more features. Note that it's not because it's named reactive that you have to use a reactive development model. It does support both, and is faster than classic in both cases.
It is confusing that it seems you have to mix reactive dependencies (for @RunOnVirtualThread) with non-reactive dependencies now. Can't virtual threads work together with reactive methods or can't virtual threads be supported by the classic dependencies to not have that mixup?
I think you mean what did I use resteasy reactive? It's because we need to control the dispatching. Only resteasy reactive let us do that. In addition, it provides more feature, it's faster and is better integrated than "classic". Note that your code does not care.
@@clementescoffier thanks for clarification. I'm aware that reactive dependencies support both non reactive and reactive style nowadays, but it's still confusing from the perspective of a person who uses classic dependencies, as he now has to include a reactive one out of the sudden. But it's confusing in the first place, that there are even those classic dependencies still available, when you can do the same with the reactive ones. Are there any plans to get rid of the classic dependencies and just keep the reactive?
@@mkluehI agree it can be confusing. For RESTEasy, we strongly recommend RESTEasy Reactive. We don't plan to remove completely RESTEasy classic, but we are not improving the integration anymore. One of the thing to understand (I'm writing a blog post about it) is that to properly integrate virtual threads you need to be able to control how (on which kind of thread) you dispatch. A "all on virtual thread" switch is not going to work well due to pinning, monopolization or others issues. With our integration, you can still decide. If you realize that for some endpoints the virtual thread is underperforming, you can still switch to (platform) worker thread, or if you really need concurrency, switch to reactive (for that endpoint).
![Megan Thee Stallion - Neva Play (feat. RM) [Official Video]](http://i.ytimg.com/vi/TpYTyAaTRts/mqdefault.jpg)
thanks Clement
is there any performance gain after using Virtual Threads and how significant is it?
Superb...
What i do not get: why does one have to use reactive version of db access? I thought one big advantage of virtual threads is that it will detach from the os thread whenever blocking occurs so making it a good choice when dealing with blocking apis as in classic jdbc drivers. Have i got sth wrong?
It does not use a reactive version for the database access. It only uses resteasy reactive, because we have more control on the dispatching strategies. That's something we cannot control with the classic resteasy. In addition resteasy reactive has a lot more features. Note that it's not because it's named reactive that you have to use a reactive development model. It does support both, and is faster than classic in both cases.
It is confusing that it seems you have to mix reactive dependencies (for @RunOnVirtualThread) with non-reactive dependencies now. Can't virtual threads work together with reactive methods or can't virtual threads be supported by the classic dependencies to not have that mixup?
I think you mean what did I use resteasy reactive? It's because we need to control the dispatching. Only resteasy reactive let us do that. In addition, it provides more feature, it's faster and is better integrated than "classic". Note that your code does not care.
@@clementescoffier thanks for clarification. I'm aware that reactive dependencies support both non reactive and reactive style nowadays, but it's still confusing from the perspective of a person who uses classic dependencies, as he now has to include a reactive one out of the sudden. But it's confusing in the first place, that there are even those classic dependencies still available, when you can do the same with the reactive ones. Are there any plans to get rid of the classic dependencies and just keep the reactive?
@@mkluehI agree it can be confusing. For RESTEasy, we strongly recommend RESTEasy Reactive. We don't plan to remove completely RESTEasy classic, but we are not improving the integration anymore.
One of the thing to understand (I'm writing a blog post about it) is that to properly integrate virtual threads you need to be able to control how (on which kind of thread) you dispatch. A "all on virtual thread" switch is not going to work well due to pinning, monopolization or others issues. With our integration, you can still decide. If you realize that for some endpoints the virtual thread is underperforming, you can still switch to (platform) worker thread, or if you really need concurrency, switch to reactive (for that endpoint).