Running tests for https://github.com/franz1981/fortune-benchmark/blob/main/fortune-virtual-thread-jdbc-mariadb/src/test/java/me/escoffier/fortune/virtual/jdbc/mariadb/test/FortuneApiTest.java shows that Agroal is using Narayana transaction manager to get the transaction, which will piggyback to ThreadActionData.currentAction which, in turn, would create a new ThreadLocal per each new request, if running from a VirtualThread.

From a functional perspective, ThreadLocal(s) on virtual thread(s), just work, but from a performance perspective they requires to allocate a N entries Map for for the internal thread local map (once on thread creation), while used, which is not great.

Other RH products are equally affected, see https://github.com/quarkusio/quarkus/issues/39696

I can see that there's no ThreadLocal::remove on that same class, meaning that using ThreadLocal is still prone to memory leak (see https://github.com/smallrye/smallrye-context-propagation/issues/424#issuecomment-1594358010 for more info): ideally using a generic ThreadLocalStorage  which can be backed by a ConcurrentHashMap<Thread, ... or ThreadLocal depending if the caller is virtual or not, would be great.