Virtual Threads and JDBC/Hibernate: Carrier Pinning Risk During Zero-Downtime Migration

A small thread-per-request application running on Java 21 or later may attempt a zero-downtime migration to virtual threads by swapping the servlet container executor. The goal is to preserve request throughput and avoid carrier-thread pinning when the data layer blocks on JDBC and Hibernate operations.

Because the executor is typically fixed at application startup, a live cutover usually requires a feature flag or dual deployment rather than a simple JVM flag. Virtual threads park their carrier on blocking JDBC calls, but synchronized blocks, native frames, and driver internals can pin the carrier and reduce concurrency gains. Hibernate often binds sessions to thread locals, which may not map cleanly to many short-lived virtual threads.

The unresolved boundary is whether the existing JDBC driver and Hibernate session management can interoperate with virtual threads without persistent pinning during live traffic. Version-specific driver compatibility and Hibernate release behavior remain uncertain without verification.

Does the target JDBC driver pin virtual threads during database I/O, and how can carrier-thread pinning be observed before a production cutover? Can Hibernate session contexts be safely rebound across virtual-thread request boundaries without connection-pool starvation? What traffic-switching pattern supports a zero-downtime executor change while keeping the old thread-per-request path available for rollback?