[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
and
authcore -> dbhelpers -> ... -> 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.

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