[SERVER-30332] Slice `db_raii` classes Created: 25/Jul/17 Updated: 11/Aug/17 Resolved: 11/Aug/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | ADAM Martin (Inactive) | Assignee: | ADAM Martin (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Platforms 2017-07-31, Platforms 2017-08-21 |
| Participants: |
| Description |
|
In making changes for authorization manager with respect to downgrade concerns, it became apparent that there were potential future circularity concerns between the authorization code and the `db_raii` code. To this end, the `db_raii` classes should be sliced via Pimpls with opaque facades with dependency injection to facilitate call compatibility while preventing a future cycle. |
| Comments |
| Comment by Andrew Morrow (Inactive) [ 11/Aug/17 ] |
|
Very likely that this will be fixed via a different approach, closing this as wont fix. We can always re-open it later if we decide again that this is the right solution. |
| Comment by ADAM Martin (Inactive) [ 27/Jul/17 ] |
|
kaloian.manassiev The cycles we're encountering are not really through sharding. They're through the DBCommand components. DBCommand directly depends upon authcore. We want to use some `mongo::Helper::` calls within authcore, but those helpers, and the db_raii components needed to safely create parameters for those functions all depend upon the DBCommand components. The cycles we have to deal with are basically: authcore -> db_raii -> ... -> curop -> commands -> authcore So slicing `db_raii` is the first step. schwerin I will run the microbenchmarks, but I expect no significant deviation here – prior to this, the calls to dbraii critical functionality were across link boundaries anyhow. In a static build, such calls would be slightly faster. In a dynamic build, they would be slightly slower. A vtable call is almost exactly between both of those. A microbenchmark is still in order, of course; however, I expect no radical degredation in performance. |
| Comment by Kaloian Manassiev [ 26/Jul/17 ] |
|
Before you do this, can you also see whether the cycles can be resolved by just pulling out AutoGetCollectionForRead/AutoGetCollectionForReadCommand/AutoGetCollectionOrViewForReadCommand/OldClientContext. This RAII class should only contain operations related to locking and obtaining the database/collection. All the sharding checks and etc can be pulled in another library, which depends on db_raii. |
| Comment by Andy Schwerin [ 26/Jul/17 ] |
|
Please run the microbenchmarks before committing a change. The dbraii types are used at least once per read operation, and so might affect operation latency. |