pgjdbc/pgjdbc GitHub issues and pull requests (mirror)  

help / color / mirror / Atom feed

From: Sanne (@Sanne) <[email protected]>
To: pgjdbc/pgjdbc <[email protected]>
Subject: Re: [pgjdbc/pgjdbc] issue #3693: Overhead of uncontended use of ResourceLock
Date: Mon, 30 Jun 2025 10:46:49 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

> The thing is pgjdbc is wildly used in many applications, so we want to avoid breakages even for the clients who are not doing the best possible thing.

Right I appreciate that. I'll think about it - just not sure yet how anyone could possibly have relied on this, without additional thread coordination from their part as well: it seems to me that the lock within the client wouldn't have the right granularity to allow such usage: if one _needed_ to run getWarnings _after_ another operation, they'd need to guarantee ordering of those two operations, and this would belong in their code.

>  Do you think you could share the source data for it? (I mean stacks.txt file or jfr or whatever was the raw data for the flamegraph)

This one was produced directly by asynch-profiler and I don't have the source data but I can easily produce jfrs instead if you prefer - would you want to suggest exact settings you'd want to see?

> An interesting experiment could be to replace ResourceLock with a dummy class that does nothing

I was planning to do that, yes. 

> Sure Caffeine is an option, and we "discuss" it here: https://github.com/pgjdbc/pgjdbc/issues/345#issuecomment-320901092
The default artifact will likely shadow Caffeine to avoid clashes with pgjdbc users' Caffeine though.

That's nice but as a technical detail I'd very much prefer to inject my own instance rather than have it shaded within the driver for various reasons, such as minimize the number of classes being loaded (we'd be using Caffeine for other reasons too) and our ability to optimise for GraalVM as well: Caffeine is tricky to handle efficiently in native images and if you were to shade it I'd have to maintain ad-hoc rules for that. But thanks to the pointer I will follow the linked discussion.

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