Use of Loom in JDBC Connection pools

[Ron Pressler]

Hi.

cogman is correct.

1. To make the best of virtual threads, frequent IO operations should be guarded by j.u.c locks 
rather than native monitors (synchronized blocks or methods). Using synchronized to guard memory 
operations or infrequent IO operations — such as those performed at startup — is fine.

2. A system has many limited resources, including number of threads, number of sockets, and number
of DB connections. Virtual threads remove the thread limitation (or, more precisely, make the limit
much higher), and make dealing with other limited resources easier. Suppose that, to process 
requests, your server needs to talk to a relational DB and a number of microservices, each with its 
own resource limitation. Instead of having multiple thread pools each serving a different subtask 
of the request — say a pool of size 100 to service DB requests, a pool of size 200 for one 
microservice call, and a pool of size 300 to service calls to another microservice etc. — you just 
limit each resource individually with its own semaphore (and a DB connection pool serves as a 
semaphore), and then your virtual threads, which are never pooled, perform blocking operations as 
needed on each of the resources without need to submit subtasks to relevant thread pools, and the 
semaphores take care of resource limits.

— Ron

> On 15 Jul 2021, at 20:09, Janez Kuhar <janez.kuhar at protonmail.com> wrote:
> 
> In an issue of the HikariCP project, there has been a suggestion that HikariCP use a combination of a semaphore and virtual threads in favour of a Connection pool.
> 
> The link to the issue:
> https://github.com/brettwooldridge/HikariCP/issues/1463
> 
> I was wondering what were the thoughts of the Loom devs on the comments made by [cogman](https://github.com/cogman) ([Thomas May](https://github.com/cogman)) in the above linked issue.
> 
> Janez Kuhar