[SERVER-27660] remove ConnectionPool class (only used by BackgroundSync to get a DBClientConnection) Created: 12/Jan/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 3.5.1 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Backlog - Service Architecture |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | sa-remove-fv-backlog-22 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Service Arch
|
| Participants: |
| Description |
|
The ConnectionPool class is only used in a lambda by BackgroundSync rollback, and all the lambda does is get the underlying DBClientConnection. The lambda is stored in RollbackSourceImpl and called to get the DBClientConnection to run some simple commands (here, here, here, and here). It seems unnecessary to have an entire connection pool (and ConnectionPool class to manage it) just to occasionally (for rollback) get a DBClientConnection to run a few commands. Perhaps it would be more straightforward to just give RollbackSourceImpl a unique_ptr<DBClientConnection> the way ConnectionPool::acquireConnection() internally does. This is especially true since ConnectionPool is always created with a nullptr NetworkConnectionHook anyway (the other constructor is only called by this constructor). Possibly neweng. |
| Comments |
| Comment by Spencer Brody (Inactive) [ 29/May/18 ] |
|
We had hoped this would fall out for free in the Recoverable Rollback project, but it didn't. The current code works fine for the needs of the replication team, so I'm kicking this ticket over to platforms to see if they want to do it as part of their effort to clean up egress networking. |