diff options
Diffstat (limited to 'src/mongo/s/commands/cluster_write_cmd.cpp')
| -rw-r--r-- | src/mongo/s/commands/cluster_write_cmd.cpp | 26 |
1 files changed, 0 insertions, 26 deletions
diff --git a/src/mongo/s/commands/cluster_write_cmd.cpp b/src/mongo/s/commands/cluster_write_cmd.cpp index 637ad92085d..8590832acc6 100644 --- a/src/mongo/s/commands/cluster_write_cmd.cpp +++ b/src/mongo/s/commands/cluster_write_cmd.cpp @@ -145,11 +145,6 @@ boost::optional<WouldChangeOwningShardInfo> getWouldChangeOwningShardErrorInfo( void handleWouldChangeOwningShardErrorRetryableWrite(OperationContext* opCtx, BatchedCommandRequest* request, BatchedCommandResponse* response) { - // Strip write concern because this command will be sent as part of a - // transaction and the write concern has already been loaded onto the opCtx and - // will be picked up by the transaction API. - request->unsetWriteConcern(); - // Strip runtime constants because they will be added again when the API sends this command // through the service entry point. request->unsetLegacyRuntimeConstants(); @@ -318,11 +313,6 @@ bool handleWouldChangeOwningShardError(OperationContext* opCtx, auto& readConcernArgs = repl::ReadConcernArgs::get(opCtx); readConcernArgs = repl::ReadConcernArgs(repl::ReadConcernLevel::kLocalReadConcern); - // Ensure the retried operation does not include WC inside the transaction. The - // transaction commit will still use the WC, because it uses the WC from the opCtx - // (which has been set previously in Strategy). - request->unsetWriteConcern(); - documentShardKeyUpdateUtil::startTransactionForShardKeyUpdate(opCtx); // Clear the error details from the response object before sending the write again response->unsetErrDetails(); @@ -507,22 +497,6 @@ bool ClusterWriteCmd::InvocationBase::runImpl(OperationContext* opCtx, BatchWriteExecStats stats; BatchedCommandResponse response; - // Append the write concern from the opCtx extracted during command setup. - if (!batchedRequest.hasWriteConcern()) { - batchedRequest.setWriteConcern(opCtx->getWriteConcern().toBSON()); - } - - // Write ops are never allowed to have writeConcern inside transactions. Normally - // disallowing WC on non-terminal commands in a transaction is handled earlier, during - // command dispatch. However, if this is a regular write operation being automatically - // retried inside a transaction (such as changing a document's shard key across shards), - // then batchedRequest will have a writeConcern (added by the if() above) from when it was - // initially run outside a transaction. Thus it's necessary to unconditionally clear the - // writeConcern when in a transaction. - if (TransactionRouter::get(opCtx)) { - batchedRequest.unsetWriteConcern(); - } - cluster::write(opCtx, batchedRequest, &stats, &response); bool updatedShardKey = false; |