Skip to content

Commit 1be250f

Browse files
authored
docs: clarify how async updates can overtake each other (#3581)
Clarify how async update statements can overtake each other on the network, and how this means that multiple async updates should preferably block for a result to be returned before sending the next one.
1 parent 71c3063 commit 1be250f

File tree

1 file changed

+10
-10
lines changed

1 file changed

+10
-10
lines changed

google-cloud-spanner/src/main/java/com/google/cloud/spanner/TransactionContext.java

+10-10
Original file line numberDiff line numberDiff line change
@@ -121,11 +121,11 @@ default ApiFuture<Void> bufferAsync(Iterable<Mutation> mutations) {
121121
/**
122122
* Same as {@link #executeUpdate(Statement,UpdateOption...)}, but is guaranteed to be
123123
* non-blocking. If multiple asynchronous update statements are submitted to the same read/write
124-
* transaction, the statements are guaranteed to be submitted to Cloud Spanner in the order that
125-
* they were submitted in the client. This does however not guarantee that an asynchronous update
126-
* statement will see the results of all previously submitted statements, as the execution of the
127-
* statements can be parallel. If you rely on the results of a previous statement, you should
128-
* block until the result of that statement is known and has been returned to the client.
124+
* transaction, the statements are guaranteed to be sent to Cloud Spanner in the order that they
125+
* were submitted in the client. This does however not guarantee that Spanner will receive the
126+
* requests in the same order as they were sent, as requests that are sent partly in parallel can
127+
* overtake each other. It is therefore recommended to block until an update statement has
128+
* returned a result before sending the next update statement.
129129
*/
130130
ApiFuture<Long> executeUpdateAsync(Statement statement, UpdateOption... options);
131131

@@ -181,11 +181,11 @@ default ResultSet analyzeUpdateStatement(
181181
/**
182182
* Same as {@link #batchUpdate(Iterable, UpdateOption...)}, but is guaranteed to be non-blocking.
183183
* If multiple asynchronous update statements are submitted to the same read/write transaction,
184-
* the statements are guaranteed to be submitted to Cloud Spanner in the order that they were
185-
* submitted in the client. This does however not guarantee that an asynchronous update statement
186-
* will see the results of all previously submitted statements, as the execution of the statements
187-
* can be parallel. If you rely on the results of a previous statement, you should block until the
188-
* result of that statement is known and has been returned to the client.
184+
* the statements are guaranteed to be sent to Cloud Spanner in the order that they were submitted
185+
* in the client. This does however not guarantee that Spanner will receive the requests in the
186+
* same order as they were sent, as requests that are sent partly in parallel can overtake each
187+
* other. It is therefore recommended to block until an update statement has returned a result
188+
* before sending the next update statement.
189189
*/
190190
ApiFuture<long[]> batchUpdateAsync(Iterable<Statement> statements, UpdateOption... options);
191191
}

0 commit comments

Comments
 (0)