Hey @U0K1KAJTB it's all deterministic, so work is repeated by each node

> if I have five nodes, will each of them process the transaction and update the document (5 times)? essentially yes, except transaction functions will eventually stop being evaluated, as the resulting tx-ops 'replace' the underlying argument document

> a buggy tx fn that crashed is this with 1.23.1? which exception did you see?

The tx fn was calling out to a function in a local namespace. I deliberately threw an exception inside that function to see how it would behave. I was using 1.23.1.

so the tx fn itself was just myns.core/explode

> I deliberately threw an exception any exception in particular?

(throw (ex-info "boom" {:fail true}))

> Is this intended behaviour? on reflection yes I believe so - after the first successful evaluation of the transaction function the node(s) will write the results back to the document store so that any subsequent nodes don't have to re-evaluate the functions (this is important for eviction) so at that point whether or not they have the buggy code is irrelevant .... until someone submits another transaction with an invocation, then the cycle will repeat (assuming the buggy node keeps being buggy)

Hey @U050N4M9Z spinning-up-as-needed won't be instant, and undoubtedly it gets slower as your database grows. https://docs.xtdb.com/administration/checkpointing/ is definitely helps but there is ultimately still a limit on how much that can reduce the cold start time (i.e. GBs = minutes, even with S3 in the same region). Are you using AWS? The choice of JDBC vs Kafka doesn't really affect the practicalities of node startup time.

For this client, yes, AWS is the preferred environment. Is that minutes with checkpointing? That probably pushes it out too far, though it might be interesting to explore something like SnapStart.

> Is that minutes with checkpointing? Yes, it comes down to S3 transfer times.

Another option that we've not explored heavily before is using EFS/EBS

You can mount remote fs storage quite quickly

That’d be fastER, for sure. Might even be close to SnapStart, since that still has to restore a snapshot from (hidden) EBS.

Cool, well, I'd be happy to help somehow and certainly very curious to hear how that goes if you do try it 🙂

Updated with the recording: https://discuss.xtdb.com/t/video-virtual-meetup-4-recording-transaction-functions-constraints/161

thanks again, sir. great stuff

Hey @UGNMGFJG3 you could use a transaction function for this (see the 'counter' example in the docs for inspiration), but before blindly recommending that...how come you want to use an auto-incrementing ID and not a UUID?

For order numbers I want to use something the people find easy to read.

That seems like a fair use case. I don't know what the ideal tradeoff would be or what the state-of-the-art is for helping end users work with UUIDs :thinking_face:

do you need like a “tracking reference” that people need to type/paste in? or why does readability matter… sequences always require coordination which slows things down, but you can always create fresh uuids without needing coordination

It appears on their billing statement so I would an easy to read identifier.

You could also have a uuid doc id and another attribute that generates successive ids, but perhaps thats just kicking the can down the road

I have a few identifiers that I wanted to be human-readable so I've been generating a random sequence of alphanumeric characters with a uniqueness check, just did some rough calculations to make sure my random string is long enough to make collisions very very unlikely with the amount of traffic I expect. Might work for you?

I can use ULID.