Fork me on GitHub
#xtdb
<
2020-03-27
>
dgr17:03:22

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. 🙂

refset17:03:36

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 🙏

jarohen17:03:01

^^ what @U899JBRPF said 🙂

🎉 4
dgr17:03:11

OK for now. If you add anything in the future that would fail like CAS, the programmer needs some way to distinguish what went wrong and what to do next. With CAS, I definitely want to retry. With other CAS-like primitives, I might not.