Summary
BatchReadOnlyTransaction::execute takes &mut self, preventing concurrent execution of multiple partitions. This makes it impossible to leverage Spanner's partitioned query/read parallelism.
In the Go client, multiple goroutines can call Execute concurrently on the same *BatchReadOnlyTransaction (via sync.Mutex). In Rust, the &mut chain from SessionHandle through RowIterator makes this infeasible without significant refactoring.
Possible approaches
- Interior mutability (Mutex on session): would serialize streaming, defeating the purpose
- New
execute_concurrent method with owned session: more API surface, but cleaner abstraction
- Make
Client::get_session and RowIterator::new public (2 visibility changes): consumers acquire a separate session per partition. Works because each Partition embeds the transaction_selector -- the Spanner server uses the same snapshot regardless of which session executes it. Minimal, non-breaking
Reference
Summary
BatchReadOnlyTransaction::executetakes&mut self, preventing concurrent execution of multiple partitions. This makes it impossible to leverage Spanner's partitioned query/read parallelism.In the Go client, multiple goroutines can call
Executeconcurrently on the same*BatchReadOnlyTransaction(viasync.Mutex). In Rust, the&mutchain fromSessionHandlethroughRowIteratormakes this infeasible without significant refactoring.Possible approaches
execute_concurrentmethod with owned session: more API surface, but cleaner abstractionClient::get_sessionandRowIterator::newpublic (2 visibility changes): consumers acquire a separate session per partition. Works because eachPartitionembeds thetransaction_selector-- the Spanner server uses the same snapshot regardless of which session executes it. Minimal, non-breakingReference
batch.go,transaction.go:858