If I correctly understand the routine for runTransaction(), as referenced below, then when running a read-write transaction, a documents:beginTransaction request is always issued before running the updateFn.

This means we wait for an entire network round trip before beginning the transaction, every attempt.

I also noticed that the documents:runQuery and documents:batchGet APIs support a newTransaction parameter, which would allow the SDK to lazily start a transaction on the first read request, without the additional sequential network round trip.

Lazily starting the transaction on the first read would always eliminate one entire sequential network round trip for every read-write transaction. I feel that this is quite a significant impact for high performance applications.

Some implications

• The transaction would be started server-side on first read (eliminate documents:beginTransaction and use newTransaction).
• All read operations would need to use documents:batchGet, documents:runQuery, documents: runAggregationQuery (i.e. not documents:get) which is fine.
• Subsequent reads would be queued until the first read completes, so as to use that same transaction ID returned. In many cases, transaction reads would be sequential anyways, and if not, the user can improve performance of parallel initial reads using getAll(). The only exception is if there is a mix of document IDs and queries (cannot be batched together in one request). Regardless, currently all reads are queued after the documents:beginTransaction call anyways so there is no downside.
• If there are no reads before the transaction is committed, then documents:commit is called without a transaction.

Thoughts?