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)