Is this on-prem or cloud? I (and others) have been hit by network issues, i.e. silently broken TCP connections. The default behaviour of e.g. the postgresql driver is to wait forever for a packet. For postgresql you may set the socketTimeout property on the connection string. That might help if that is what is hitting you. The problem is well described here: https://github.com/brettwooldridge/HikariCP/wiki/Rapid-Recovery (Datomic on prem uses a different connection pool though, but the socketTimeout setting is the same.)

oh I see you are using on-prem

I wrote about this issue here: https://ask.datomic.com/index.php/631/blocking-event-cluster-without-timeout-failover-semantics

I also wonder if you are running in the "cloud"? My company services is running in Azure, and we have had plenty of these silently broken TCP connections. All of our code needs to have proper network timeouts, otherwise -well- requests will just block forever it seems. Waiting forever is the default of quite a few libraries (including datomic). We did not have this problem on prem (though that doesn't mean it cannot happen there of course), or at least it hardly ever happened.

Yeah, I've seen that ask.datomic thread while looking around, but not sure how much that applies, considering dynamodb backend is used in my case, not even sure if it supports some timeout parameter.

I remember reading somewhere that undocumented metrics were considered internal

There are minor differences, e.g. you can’t create/delete dbs (or perform administer-system?) with peer-server (= onprem)

but these are all the same fns from the same namespace

and all the usual stuff works the same

oh, that is cool

In cloud, is the transactor and peer one process?

@U09K620SG haven't try it, but I don't think devlocal supports custom transaction functions since that requires ions

dev-local is a single process---seems like the transaction function would only need to be available to the classloader

Ok, is not clear from the docs how you would make them available to devlocal/transactions since the examples rely on the ions api https://docs.datomic.com/cloud/transactions/transaction-processing.html#cancel

buy maybe datomic.ion is available in devlocal, haven't check

In on-prem, nothing is done to make them available--just make sure the var is in the classpath.

I suspect dev-local is the same, because it’s the same process model

ions are different, because you have to deploy the txfn to the transacting process somehow.

This question can be answered very easily in a repl with dev-local loaded. I don’t have a dev-local project handy though.

last time I checked there was no datomic.ion namespace per (ns-all)

why do you need an ion namespace to write a transaction function?

for using stuff like cancel https://docs.datomic.com/cloud/transactions/transaction-processing.html#cancel

oh, you mean what environment is available to the txfn

I misunderstood what you meant by this:

> but I don’t think devlocal supports custom transaction functions since that requires ions

It’s easy enough to add a shim for cancel

cancel is just (throw (ex-info ..))

with some standard keys in the ex-data map

thx, will look into it, don't have the project near by right now