[SERVER-6663] Use getInternalScopedDbConnection in all places that do "internal" operations, even if they're not using commands. Created: 31/Jul/12 Updated: 08/Mar/13 Resolved: 26/Feb/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security, Sharding |
| Affects Version/s: | 2.2.0-rc0 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
Not actually tried, but we should check if this works (Note that we need to add admin users in the config databases to simulate remote access in an auth environment when testing). Suspicious code in ConfigServer::replicaSetChange:
Shouldn't this be using getInternalScopedDbConnection instead? |
| Comments |
| Comment by Spencer Brody (Inactive) [ 26/Feb/13 ] |
|
Better fix is |
| Comment by Spencer Brody (Inactive) [ 03/Aug/12 ] |
|
This won't be a problem because the connection is only used for an update operation, not a command. The difference between getScopedDbConnection and getInternalScopedDbConnection only matters when running commands. You're right though that this is an internal operation, so arguably should be using an internal connection anyway, if we want to be pedantic about the definition of "internal" connection. There are definitely other places in the code right now where we're using getScopedDbConnection for internal operations that don't use any commands, not sure it's worth hunting those down until/unless the definition of getInternalScopedDbConnection changes to make it different for more than just commands. |