From 6b1b85870869c8bd5040134ea0999d1bf480dfb6 Mon Sep 17 00:00:00 2001 From: Rolfe Dlugy-Hegwer Date: Thu, 19 Oct 2023 07:11:43 -0400 Subject: [PATCH] Add note that pinning cases section is historical information. --- docs/src/main/asciidoc/virtual-threads.adoc | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/docs/src/main/asciidoc/virtual-threads.adoc b/docs/src/main/asciidoc/virtual-threads.adoc index 015f3ff65e1c1..93bbc15465d1e 100644 --- a/docs/src/main/asciidoc/virtual-threads.adoc +++ b/docs/src/main/asciidoc/virtual-threads.adoc @@ -134,13 +134,16 @@ According to link:{vthreadjep}[JEP 425] this can happen in two situations: - when it executes a blocking operation inside a native method or a foreign function It can be reasonably easy to avoid these situations in your code, but verifying every dependency you use is hard. -Typically, while experimenting with virtual threads, we realized that old versions of the link:{pgsql-driver}[postgresql-JDBC driver] -results in frequent pinning. +Typically, while experimenting with virtual threads, we realized that versions older than 42.6.0 of the link:{pgsql-driver}[postgresql-JDBC driver] result in frequent pinning. Most JDBC drivers still pin the carrier thread. -Even worse, lots of widespread libraries are pinning and would require code changes. +Even worse, many libraries require code changes. For more information, see link:https://quarkus.io/blog/virtual-thread-1/[When Quarkus meets Virtual Threads] +IMPORTANT: This information about pinning cases applies to PostgreSQL JDBC driver 42.5.4 and earlier. +For PostgreSQL JDBC driver 42.6.0 and later, virtually all synchronized methods have been replaced by reentrant locks. +For more information, see the link:https://jdbc.postgresql.org/changelogs/2023-03-17-42.6.0-release/[Notable Changes] for PostgreSQL JDBC driver 42.6.0. + [[pooling]] ==== The pooling case Some libraries are using `ThreadLocal` as an object pooling mechanism.