Fork me on GitHub
#sql
<
2020-03-20
>
onetom06:03:39

is there a way to specify a timeout for next.jdbc/get-connection?

onetom07:03:48

actually, i might be experiencing some other kind of timeout, since im accessing my db server over a ssh socks proxy which is tunnelled to my machine also over ssh this is my proxy handling code, if anyone is curious:

(defn proxy-props [& [props]]
  (->> (or props (System/getProperties))
       (filter #(str/includes? (key %) "Proxy"))
       (into {})))

(defn activate-socks-proxy! [host port]
  (proxy-props
    (doto ^Properties (System/getProperties)
      (.setProperty "socksProxyHost" host)
      (.setProperty "socksProxyPort" (str port)))))

(defn deactivate-socks-proxy! []
  (proxy-props
    (doto ^Properties (System/getProperties)
      (.remove "socksProxyHost")
      (.remove "socksProxyPort"))))


(comment
  (proxy-props)
  (activate-socks-proxy! "localhost" 1081)
  (deactivate-socks-proxy!)
  )

seancorfield15:03:19

You should be able to specify :loginTimeout in the db spec used to create the datasource (that you then get the connection from) @onetom

onetom15:03:43

Thanks! So I guess I have to read the various JDBC adapter's documentation to figure out what kind of options do they support.

seancorfield15:03:25

On a statement level, you can specify :timeout in the options (anywhere a prepared statement would be created and executed) -- that one is in the documentation (see *All the Options* and elsewhere).

onetom15:03:00

Yes, I found that and it was clearly explained; no issue there

seancorfield15:03:17

The former -- :loginTimeout -- is not specifically documented, but I believe the docs explain that arbitrary options can be passed through to the get connection process from the db spec hash map?

onetom15:03:29

Yes, the arbitrary option passing is explained, I just didn't have the intuition what to google for, since I'm not familiar with the JDBC ecosystem...

seancorfield21:03:03

I'm not certain that :loginTimeout would actually propagate correctly from the options to the driver or the datasource. For any code using an actual javax.sql.DataSource object (such as connection pooling), there is (.setLoginTimeout ds n) which tells JDBC to wait up to n seconds for a connection to the database to be made before throwing an exception. That isn't directly possible right now for the reified DataSource that is created when you call get-datasource on a hash map or a (JDBC) string, but I've just implemented a way for that to happen on master for the next release: the reified DataSource will support .getLoginTimeout and .setLoginTimeout and implements it by using DriverManager/setLoginTimeout immediately prior to calling DriverManager/getConnection. It's not ideal, but it should be sufficient for "casual use". For production-level use, you should already be using connection pooling anyway.

👍 4
seancorfield21:03:03

I'm not certain that :loginTimeout would actually propagate correctly from the options to the driver or the datasource. For any code using an actual javax.sql.DataSource object (such as connection pooling), there is (.setLoginTimeout ds n) which tells JDBC to wait up to n seconds for a connection to the database to be made before throwing an exception. That isn't directly possible right now for the reified DataSource that is created when you call get-datasource on a hash map or a (JDBC) string, but I've just implemented a way for that to happen on master for the next release: the reified DataSource will support .getLoginTimeout and .setLoginTimeout and implements it by using DriverManager/setLoginTimeout immediately prior to calling DriverManager/getConnection. It's not ideal, but it should be sufficient for "casual use". For production-level use, you should already be using connection pooling anyway.

👍 4