This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-28
Channels
- # announcements (11)
- # aws (2)
- # babashka (35)
- # beginners (173)
- # calva (3)
- # chlorine-clover (2)
- # cider (17)
- # clara (2)
- # clj-kondo (28)
- # cljs-dev (11)
- # cljsrn (53)
- # clojure (178)
- # clojure-argentina (1)
- # clojure-europe (12)
- # clojure-germany (5)
- # clojure-italy (4)
- # clojure-nl (5)
- # clojure-spec (25)
- # clojure-uk (88)
- # clojurescript (109)
- # conjure (34)
- # cursive (2)
- # data-science (35)
- # datomic (15)
- # emacs (6)
- # events (1)
- # fulcro (28)
- # graphql (15)
- # helix (21)
- # hoplon (7)
- # jobs (4)
- # jobs-discuss (1)
- # joker (15)
- # lambdaisland (1)
- # lein-figwheel (4)
- # local-first-clojure (1)
- # malli (8)
- # meander (17)
- # off-topic (33)
- # parinfer (2)
- # rdf (16)
- # re-frame (3)
- # reagent (21)
- # reitit (14)
- # remote-jobs (5)
- # ring (8)
- # rum (1)
- # shadow-cljs (184)
- # sql (2)
- # testing (1)
- # tools-deps (23)
If anyone is using next.jdbc
in such a way that they are managing their own Connection
objects and trying to pass those directly into with-transaction
or transact
, could you please try the version on master to see how the addition of a locking
call behaves in that situation? This is intended to be a fix for https://github.com/seancorfield/next-jdbc/issues/106 although my gut reaction is that trying to run multi-threaded code that might attempt to set up a transaction on a shared (mutable) Connection
object is just a bad idea and you should get what you deserve... 🙂
(the locking
call is only present for cases where you provide a Connection
to the transaction functions -- if you are using a DataSource
, or even a JDBC URL or db-spec hash map, no locking
call is needed because those functions will create and manage a fresh Connection
object of their own, locally)