This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-07-10
Channels
- # announcements (1)
- # babashka (17)
- # biff (7)
- # calva (6)
- # clerk (5)
- # clj-on-windows (1)
- # clojure (59)
- # clojure-austin (17)
- # clojure-brasil (1)
- # clojure-europe (40)
- # clojure-nl (2)
- # clojure-norway (103)
- # clojure-sweden (9)
- # clojure-uk (8)
- # clojurescript (8)
- # cursive (25)
- # data-science (5)
- # datalevin (7)
- # datomic (4)
- # emacs (8)
- # etaoin (13)
- # hyperfiddle (26)
- # lsp (8)
- # malli (7)
- # off-topic (9)
- # polylith (13)
- # releases (2)
- # sql (7)
For any MySQL users:
The 9.0.0 connector-j
is available now that rewrites all the synchronized
stuff to use ReentrantLock
so that the driver is compatible with virtual threads.
My reading of that (long) thread is that Hikari doesn't use synchronized
on any critical path so it "doesn't matter". What is a real issue is vthread code overwhelming the connection pool and getting timeouts - which is already a problem with native thread code, but perhaps more likely with vthread code.
No one provided a repro case of pinning within Hikari...
Interesting. There are other discussions in the issues tab that talk about it. However, worth a shot I think! I'm happy for the connector change too! 🙂
Databases have a limit on concurrent connections so you can't have unlimited pool sizes anyway - so there has to be some throttling somewhere.
(we've already updated at work and we're starting to use vthreads -- finally! -- and we're not seeing any pinned o/s threads so... yay!)