Message-ID: <gh-pgjdbc-pgjdbc-3703@github.com>
From: "vlsi (@vlsi)" <noreply+vlsi@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Tue, 01 Jul 2025 20:05:34 +0000
Subject: [pgjdbc/pgjdbc] PR #3703: fix: remove excessive ReentrantLock.lock usages
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Id: 213894
X-GitHub-Author-Login: vlsi
X-GitHub-Issue: 3703
X-GitHub-Labels: performance
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-State: merged
X-GitHub-Type: pull_request
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/3703
Content-Type: text/plain; charset=utf-8

In some of the cases (private/protected/internal API) we know we already hold the lock, so there's no much sense aquiring it again.

For LruCache, we know we do not perform IO operations, so it is safe to use synchronized as it won't cause Loom virtual thread pinning.

See https://github.com/pgjdbc/pgjdbc/issues/3693

Frankly speaking, I wasn't able to measure any significant difference for before vs after.

On the other hand, removing the excessive try-with-resources and excessive `ReentrantLock.lock/unlock` should be a net positive change.

Note: the results in https://github.com/pgjdbc/pgjdbc/issues/3693 show there's a significant share of locking in `org.postgresql.core.QueryExecutorBase#getTransactionState`, however, the method is used in many places that do not currently aquire the lock (e.g. `PgConnection#commit`), so I did not update `getTransactionState` yet.