This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-07
Channels
- # beginners (49)
- # boot (48)
- # cider (5)
- # cljs-dev (6)
- # clojure (165)
- # clojure-android (1)
- # clojure-austin (1)
- # clojure-india (2)
- # clojure-italy (23)
- # clojure-nl (2)
- # clojure-poland (4)
- # clojure-russia (63)
- # clojure-spec (5)
- # clojure-uk (121)
- # clojurescript (187)
- # core-async (1)
- # core-logic (4)
- # cursive (17)
- # datascript (1)
- # datomic (12)
- # emacs (2)
- # funcool (3)
- # hoplon (2)
- # jobs (7)
- # juxt (6)
- # lambdaisland (1)
- # luminus (2)
- # lumo (20)
- # midje (8)
- # off-topic (11)
- # om (38)
- # onyx (42)
- # pedestal (6)
- # planck (23)
- # protorepl (29)
- # ring (3)
- # rum (23)
- # spacemacs (6)
- # untangled (70)
- # vim (1)
Hi @favila
Done some thinking. Yesterday you asked
> are you creating and destroying connections frequently, maybe inadvertently?
It was my understanding that calling datomic connections were cached, calling (d/connect)
on the same uri multiple times just returned the same connection and it was never destroyed.
Could you elaborate on what you meant by creating/destroying a connection?
Lets say my code does something similar to this for example:
(doseq [n (range 10000)]
(d/transact (d/connect uri) tx))
Is calling d/connect
in quick succession not advised and should i be passing a connection whenever doing frequent transactions? Could this be the cause?@mbutler I was talking about a d/connect d/release lifecycle pair. I was speculating you had some lifecycle management in your app. I think release is async, or else maybe you exposed a race in datomic. All pure speculation, none of it ended up applying to your case
Okay, no problem. So in theory calling (d/connect uri)
is functionally identical to passing around an established connection. I performed the refactor anyway as im at a loss 🙂
@jonpither very easy to get running, but we haven't tested a production workload yet and are not using a high-availability transactor yet
d/release
is only necessary if you know you are not going to use that connection again, and the java process is going to stick around. For processes which keep a database connection for their entire lifetime, d/release
is not needed.
d/connect
does cache connections based on the URI, so calling d/connect
repeatedly should have no effect.