This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-24
Channels
- # announcements (12)
- # aws (11)
- # babashka (1)
- # beginners (73)
- # cider (4)
- # clj-kondo (2)
- # cljsrn (4)
- # clojars (2)
- # clojure (68)
- # clojure-europe (8)
- # clojure-nl (5)
- # clojure-spec (6)
- # clojure-sweden (1)
- # clojure-uk (29)
- # clojurescript (41)
- # conjure (22)
- # datomic (33)
- # docker (58)
- # duct (3)
- # emacs (8)
- # events (1)
- # expound (3)
- # figwheel-main (5)
- # fulcro (33)
- # graphql (2)
- # kaocha (2)
- # lambdaisland (39)
- # leiningen (1)
- # nrepl (49)
- # nyc (1)
- # off-topic (77)
- # pathom (1)
- # re-frame (33)
- # reagent (28)
- # reitit (1)
- # rewrite-clj (2)
- # shadow-cljs (195)
- # spacemacs (1)
- # sql (60)
- # tools-deps (13)
- # vim (18)
- # xtdb (46)
ok this is a really odd question but ... apparently the storage service they want me to use has a READ port and a WRITE port. I've never seen this before. I'm curious if anyone has any thoughts on how this might be accomplished
correct on the READ+WRITE
mariadb on something called a galera cluster
does that just mean I pass the read string to the peers?
so if I understand this correctly, I pass the "read uri" to the peer. Peer looks up in storage location of transactor. It hands off transactions to transactor and does queries from read? Is that the theory?
got it. So it won't cause a conflict that I pass in a different string than the transactor suggests on startup?
just making sure it doesn't do some kind of validation
lovely
is this purely an access-control thing, or do they have different consistency guarantees between them? is the other port a read replica?
consistency guarantees
replica, yes. Something about performance
polite thing to do would be to respect the setup, they said, so wanted to see if I could accomodate
what I mean is, could the peer and transactor ever read different things using different ports?
transactor does a commit, and then informs peers. The peers need to be able to read what the transactor wrote
I see. Needs to be strongly consistent?
I'm not sure -- checking
"about 1 second" propagation time
Okay based on what I'm seeing here: https://docs.datomic.com/on-prem/architecture.html
It looks like updates are sent directly from the transactor to the peer
so as long as it's sending the actual data and not, say, a lookup value then we should be fine
I am not a datomic dev, but it seems like at least some things must be lookups sometimes
gotcha
I'm thinking if I had a peer service that only did upserts and another that only did reads, I could pass a write uri-string to the upsert service and a read uri-string to the query service, while having the transactor sit on the "write node".
Does that pass a sniff test...?