EclipseLinkJpaDialect singleton lock in EclipseLinkConnectionHandle.getConnection() serializes all JDBC connection acquisitions under load

[abhina-kumar]

Commit 0033eda ("Apply transactionIsolationLock in EclipseLinkConnectionHandle as well", fixing #36165) changed
EclipseLinkConnectionHandle from a private static to a private inner class, and wrapped entityManager.unwrap(Connection.class) in
getConnection() with the EclipseLinkJpaDialect's singleton-scoped transactionIsolationLock.

Since EclipseLinkJpaDialect is registered as a Spring singleton bean, this lock is shared across all threads. Under load, this serializes all JDBC connection acquisitions. Only one thread at a time can call unwrap(Connection.class), regardless of how many connections are available in the pool.

The lock is unconditional, it serializes getConnection() across all threads, even when no thread is using a custom isolation level.

Impact:

Even for applications that never use custom transaction isolation levels, all threads serialize through a single lock point when acquiring JDBC connections. Even with a connection pool of N connections, only 1 thread can acquire a connection at a time, there by the remaining N-1 connections sit idle.

Under load this leads to severe throughput degradation, connection pool exhaustion (threads stall on the lock).

Steps to reproduce:

1. Configure EclipseLinkJpaDialect with default settings (lazyDatabaseTransaction=false)
2. Use a bounded connection pool (e.g., Tomcat JDBC, 8 connections)
3. Use only ISOLATION_DEFAULT on all @transactional methods
4. Run load test with concurrent requests

Expected: All pool connections used concurrently, throughput scales with pool size

Actual: Throughput equivalent to a pool of 1. All threads serialize through the lock.

Suggested fix: The lock in getConnection() should only be acquired when a concurrent custom isolation level transaction is actually in progress.

Related:

• Introduced by: 0033eda (fix for EclipseLinkConnectionHandle can fail against transaction isolation race condition #36165)
• Spring Framework version: 6.2.x through 6.2.19, also present in main

@jhoeller

[seonwooj0810]

Would the team be open to a PR for this?

I traced the same root cause: commit 0033eda added transactionIsolationLock.lock() inside EclipseLinkConnectionHandle.getConnection(), and unlike the two call sites in beginTransaction(...) (which only lock when a custom isolation level is being applied, or to consistently pick up the default) this lock is taken unconditionally on the first connection fetch of every handle. Since EclipseLinkJpaDialect is a singleton bean, that single ReentrantLock serializes unwrap(Connection.class) across all threads even when no custom isolation is ever used.

I'd be happy to work on a fix that keeps the isolation-consistency guarantee from gh-36165 while avoiding the unconditional serialization (e.g. only guarding getConnection() when custom isolation levels are actually in play). But since I know this lock was added deliberately, I wanted to check first whether the team agrees this is worth addressing and would accept a PR.

[jhoeller]

I'm afraid there is no other way to provide consistent behavior, given how EclipseLink internally handles its transaction isolation configuration: It's a global setting that is applied on connection retrieval, and if any transaction applies a non-default isolation level, there is always the risk of a concurrent default transaction accidentally picking up the non-default isolation level. That's the reason why we need to lock unconditionally there, even for transaction without a custom isolation level.

The only way to prevent the need for such locking is to reject non-isolation levels completely. So this could be a corresponding global allowCustomIsolationLevel setting on EclipseLinkJpaDialect which could either be true by default (to be switched to false in scenarios where the locking overhead matters) or false by default so that developers need to opt into custom isolation level support for a particular application (that's a breaking change but arguably justifiable for 7.1 if the locking overhead turns out to be significant in common scenarios).

However, I have to yet to understand the actual runtime impact of our extra locking there. Connection pools typically lock on exhaustion themselves, waiting for connections to be returned, so our local locking should not really add to the contention. If a connection pool is configured to reject immediately on exhaustion, we're propagating that exception right away as well. So the only actual impact that I can see is in highly concurrent scenarios where enough connections are available in the pool, so our locking adds contention on retrieving one of those available connections. That said, that locking of ours is very short and does not affect overall processing throughput but rather just connection acquisition. For typical JPA processing against a typical connection pool setup, I am not seeing a problematic scenario there.