pgjdbc/pgjdbc GitHub issues and pull requests (mirror)
help / color / mirror / Atom feedFrom: Sanne (@Sanne) <[email protected]>
To: pgjdbc/pgjdbc <[email protected]>
Subject: [pgjdbc/pgjdbc] issue #3693: Overhead of uncontended use of ResourceLock
Date: Fri, 27 Jun 2025 14:36:00 +0000
Message-ID: <[email protected]> (raw)
**Describe the issue**
I'm running some benchmarks on a Quarkus application using Hibernate ORM and pgjdbc. While I admit there are also other bottlenecks which worry me more than this one, it's quite noticeable on flamegraphs that we spend significant CPU cycles on `ResourceLock.obtain` and `ResourceLock.close`.
While the application is heavily parallel and using many threads, the general model is that a single HTTP request is being handled within the confines of a single backend thread: there is zero contention on the pgjdbc core resources such as `PgConnection` and `QueryExecutorBase`.
I'm sure that - in our design - we actually don't need these locks at all. But I appreciate the JDBC spec requirement and the need to accommodate for other architectures.
I see multiple possibilities, not sure what you'd find acceptable:
1. Introduce a global flag (perhaps even a JVM property?) which fully disables locking: make it responsibility of the system architects to play with such a setting at their own risk.
2. Have a detailed look at some of them and try to improve the locking patterns as I have the impression that some of them are unneccessary.
For example, I *think* that in the case of `PgConnection`.`clearWarnings` one could simply remove the lock: it's guarding a `checkClosed()` invocation (which several other methods perform w/o the lock so seems acceptable) and also `queryExecutor.getWarnings();` : but the query executor has its own lock so it's definitely redundant. The method is also setting `firstWarning` to `null` but we'd be better off in replacing this with a volatile.
This is just an example, I see plenty of methods which seem to lock excessively and could be simplified.
I'd be happy to provide patches - just checking if these approaches would be acceptable?
Attaching a flamegraph as well, in case someone is interested to see them:
[flamegraph_quarkus_db_256.zip](https://github.com/user-attachments/files/20950646/flamegraph_quarkus_db_256.zip)
view thread (14+ messages) latest in thread
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] issue #3693: Overhead of uncontended use of ResourceLock
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