This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-27
Channels
- # announcements (2)
- # aws (31)
- # babashka (81)
- # beginners (82)
- # calva (38)
- # clj-kondo (41)
- # cljdoc (4)
- # cljs-dev (6)
- # clojure (101)
- # clojure-belgium (1)
- # clojure-europe (30)
- # clojure-germany (1)
- # clojure-italy (7)
- # clojure-nl (4)
- # clojure-norway (1)
- # clojure-spec (1)
- # clojure-uk (19)
- # clojurescript (16)
- # clojutre (1)
- # community-development (26)
- # core-logic (2)
- # data-science (26)
- # datomic (71)
- # events (3)
- # fulcro (55)
- # graalvm (2)
- # graphql (3)
- # joker (2)
- # kaocha (19)
- # luminus (2)
- # malli (6)
- # meander (3)
- # off-topic (6)
- # pathom (34)
- # random (1)
- # re-frame (2)
- # robots (1)
- # shadow-cljs (37)
- # sql (30)
- # tools-deps (21)
- # xtdb (4)
- # yada (25)
tx-committed?
checks whether a given transaction has committed and then returns true
or false
if so/if not. It can also throw NodeOutOfSyncException
if the node hasn’t indexed that transaction yet. Assuming the node is in-sync, is there any reason that tx-committed?
can return false
other than an unsuccessful CAS? To put it another way, is the only possible error a NodeOutOfSyncException
or could something fail for another reason (e.g., out of memory, out of disk space, etc.)? I would assume that if I submit a CAS, I would want to check tx-committed?
and then retry the transaction if it returns false
, which signals that somebody changed the document when I wasn’t looking. But if it returns false
for other reasons, that might result in an infinite loop of retries. But then how would I distinguish those failures? Or is the plan that every other failure would be signaled by throwing an exception, and the only exception right now is NodeOutOfSyncException
? And yes, I have one of those minds which naturally picks out corner cases far away from the happy path. 🙂
I'm 99% sure that tx-committed?
is only currently applicable for CAS failures. We may introduce other CAS-like logical primitives in the future (I can see use-cases for and/or combinations) but regardless, a false should only ever be returned on a logical failure of the transaction. This is the relevant issue: https://github.com/juxt/crux/issues/555
/cc @U050V1N74 for a second opinion 🙏