[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: |
|
||||||||
| 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: |
| 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... |