Canton latency for submit vs submitAndWait vs submitAndWaitForTransaction

Questions
,
1

For a single Daml command submission for which I need the resulting Transaction, is there a difference in Canton latency across the following 3 approaches:

  1. Use submit to submit the command, listen to its result on TransactionStream
  2. Use submitAndWait to submit the command, listen to its result on TransactionStream
  3. Use submitAndWaitForTransaction to submit the command and hence get result back in the same call

My understanding is that the only difference would be in how many requests I can get through per second to the participant node API using a single thread in my Java client. I would expect Canton would take the same amount of time to process the transaction in each of the 3 cases above, i.e., the point in time the command hits the pNode’s gRPC API to the point in time the resulting Transaction is emitted out of the API.

Is my understanding correct?

1 Like
2

There is no difference in the latency to the transaction being committed, but there’s a difference how fast the API call returns and what you get back.

  1. submit returns after interpretation on your local node.
  2. submitAndWait only returns after the transaction is committed, but returns nothing much.
  3. submitAndWaitForTransaction also returns after the transaction is committed, but also returns the transaction itself.
3 Likes
3

Ok so sounds like if i have a requirement to respond to the original caller with the resulting Transaction in the same call as the command submission, using submitAndWaitForTransaction puts me at no latency disadvantage but gives me an implementation complexity advantage (since I don’t have to deal with separate Command and Transaction streams).

Cheers, thanks @bernhard!