[SERVER-24701] Add option to set writeConcern for ShardingCatalogClient write ops Created: 21/Jun/16  Updated: 25/Jan/17  Resolved: 24/Jun/16

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.3.8
Fix Version/s: 3.3.9

Type: Improvement Priority: Major - P3
Reporter: Randolph Tan Assignee: Randolph Tan
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-24379 Implement addShardToZone and _configs... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 16 (06/24/16), Sharding 17 (07/15/16)
Participants:

 Description   

Everything is currently set to wMajority. But there are cases where the desired write concern is { w: 1 }. Like for example, when doing local writes while holding some resource lock that doesn't yield.



 Comments   
Comment by Githook User [ 24/Jun/16 ]

Author:

{u'username': u'renctan', u'name': u'Randolph Tan', u'email': u'randolph@10gen.com'}

Message: SERVER-24701 Add option to set writeConcern for ShardingCatalogClient write ops
Branch: master
https://github.com/mongodb/mongo/commit/4d14ddf06f49ff55c90451dcff2da1a6edcaf366

Comment by Randolph Tan [ 22/Jun/16 ]

It's because the addShardZone implementations are holding locks (and to make it worse, ones that don't yield!). So the design was to wait for replication to happen after the command finishes (when all locks are released), just like any normal command.

Comment by Spencer Brody (Inactive) [ 21/Jun/16 ]

Why don't you want to use w:majority? You still want to verify that your writes won't be rolled back...
Also, config servers currently don't even allow non w:majority writes right now.

Generated at Thu Feb 08 04:07:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.