Message-ID: From: "Sanne (@Sanne)" To: "pgjdbc/pgjdbc" Date: Mon, 30 Jun 2025 10:46:49 +0000 Subject: Re: [pgjdbc/pgjdbc] issue #3693: Overhead of uncontended use of ResourceLock In-Reply-To: References: List-Id: X-GitHub-Author-Login: Sanne X-GitHub-Comment-Id: 3018676521 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-3018676521 Content-Type: text/plain; charset=utf-8 > 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.