Question about using virtual thread

Remi Forax forax at univ-mlv.fr
Mon Jun 12 16:27:23 UTC 2023


> From: "刘希晨" <benrush0705 at gmail.com>
> To: "loom-dev" <loom-dev at openjdk.org>
> Sent: Monday, June 12, 2023 5:39:29 PM
> Subject: Question about using virtual thread

> Hi I have several questions about using virtual threads in web application:
> 1. When using per-request-per-virtual-thread style programming model, a general
> case would be to acquire a jdbc connection from some database connection pool,
> launch a SQL request, and then release the connection. I have some doubts that
> since database connections are usually a small number(like at most 100
> connections), most of the virtual threads are waiting for them if requests come
> in quite fast. In this case, should I limit the number of virtual threads to
> reduce unnecessary waiting?

With virtual threads, when a virtual thread block, another can run, so having a code that block is not an issue. 

> 2. Is it recommended to create like several thousands of virtual threads,
> waiting to perform take() from a BlockingQueue infinitely? I noticed pooling
> virtual threads is definitely not recommended, so I am a little confused about
> this idea. which really sounds like pooling, but this mechanism can control the
> virtual threads concurrency pretty easily.

Pooling means re-using the same threads for different tasks, something you have to do with platform threads (OS threads) because starting a platform thread is slooooow. 
Starting a virtual threads is way faster, so pooling virtual threads is useless. 

Now with a virtual threads, the blocking cost is not a problem if there are other virtual threads that have some work to do. If all threads (virtual or not) are blocked but one, your code will scale poorly. 

> 3. Sometimes a request may needs to perform a SQL request, sometimes not. I am
> wondering whether I should put the acquired database connection in a
> ThreadLocal or a ScopedValue. In old times, ThreadLocal would be perfect for
> this senario, however it seems that ScopedValue are preferred to be used in
> virtual threads. I noticed that the object that ScopedValue holds should remain
> unchanged during the method, but the unchanged object could have changable
> fields. So if when I receive a Http request, I create a object with a database
> connection field initialized as null, then when it needs to perform a SQL
> request, acquire a database connection and then put it into the ScopedValue's
> object, thus the later actions could all find it and use it from the
> ScopedValue.
> I don't know if it's recommended to use ScopedValue like this, which really
> looks like ThreadLocal.

Please do not try to manage the SQL connections by hand. 
Use a DataSource object, it will do the SQL Connections pooling for you. 

The only thing you have to do to support virtual threads in your application is to update your JDBC driver to the most recent version because at least in the case of Postgres, previous versions of the driver were forcing each virtual thread to block the underlying platform thread. 

> Please correct me if I am wrong, Thank you guys for your great work making Java
> better !

regards, 
Rémi Forax 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230612/b0da9edc/attachment-0001.htm>


More information about the loom-dev mailing list