pgjdbc/pgjdbc GitHub issues and pull requests (mirror)
help / color / mirror / Atom feedFrom: vlsi (@vlsi) <[email protected]>
To: pgjdbc/pgjdbc <[email protected]>
Subject: [pgjdbc/pgjdbc] PR #3703: fix: remove excessive ReentrantLock.lock usages
Date: Tue, 01 Jul 2025 20:05:34 +0000
Message-ID: <[email protected]> (raw)
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.
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: github://pgjdbc/pgjdbc
Cc: [email protected], [email protected]
Subject: Re: [pgjdbc/pgjdbc] PR #3703: fix: remove excessive ReentrantLock.lock usages
In-Reply-To: <<[email protected]>>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox