Message-ID: From: "vlsi (@vlsi)" To: "pgjdbc/pgjdbc" Date: Mon, 30 Jun 2025 07:02:12 +0000 Subject: Re: [pgjdbc/pgjdbc] issue #3693: Overhead of uncontended use of ResourceLock In-Reply-To: References: List-Id: X-GitHub-Author-Login: vlsi X-GitHub-Comment-Id: 3018029556 X-GitHub-Comment-Type: issue_comment X-GitHub-Issue: 3693 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/3693#issuecomment-3018029556 Content-Type: text/plain; charset=utf-8 @Sanne , can you please double-check you shared the right profiling results? I am afraid the file does not contain the traces of async-profiler data. --- > For example, I think that in the case of PgConnection.clearWarnings one could simply remove the lock: it's guarding a checkClosed() ... The method is also setting firstWarning to null but we'd be better off in replacing this with a volatile. Imagine the following: 1) A connection executes `copy` command 2) A different thread calls `.getWarnings()` If we remove the locking there, the noticeable behaviour will change, and we want keeping the backward compatibility: a) With locking, the second thread would have to wait for `copy` completion and then it will obtain the warnings b) Without locking, it would return no warnings Of course, the reentrant locking could probably be eliminated (e.g. we should probably aquire a lock on the top-level method, and we should refrain from reentrant acquire of the same lock). We could indeed replace certain lock instances with `synchronized` (e.g. `LruCache`), however [previously](https://github.com/pgjdbc/pgjdbc/issues/1951#issuecomment-1254442789), the understanding was that `ReentrantLock` was cheap enough. --- Benchmarks are always welcome. If you could contribute a benchmark (Quarkus + Hibernate is fine) or a link to the benchmark, that would be great.