[SERVER-37719] Make service_entry_point_common.cpp more modular Created: 23/Oct/18 Updated: 24/Aug/23 Resolved: 24/Aug/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Siyuan Zhou | Assignee: | Backlog - Service Architecture |
| Resolution: | Declined | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Service Arch
|
| Participants: |
| Description |
|
As discussed with replication team and schwerin, service_entry_point_common.cpp is hard to read, reason about and maintain. One of the reasons is that it hosts too many details in various sub-systems: command parsing, command execution, read concern, write concern, transaction, session checkout, error handling, etc. The ordering and dependencies of these sub-systems is unclear and error prone.
|
| Comments |
| Comment by Lauren Lewis (Inactive) [ 21/Dec/21 ] |
|
We haven’t heard back from you in at least 1 year, so I'm going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket. |
| Comment by Siyuan Zhou [ 23/Oct/18 ] |
|
The dependency can be hidden by decorations on operation context too. For example, TransactionParticipant is always accessible once the session is checked out. The logic after session checkout may have assumptions of the state of TransactionParticipant (e.g. it has started; or it's in progress). This kind of dependencies may not be addressed by this ticket though. Any solution of this ticket will need the input from multiple teams to define an achievable goal. |