[DRIVERS-2126] Drivers should check out an implicit session only after checking out a connection Created: 30/Sep/19 Updated: 09/Mar/22 Resolved: 09/Mar/22 |
|
| Status: | Closed |
| Project: | Drivers |
| Component/s: | Sessions |
| Fix Version/s: | None |
| Type: | Spec Change | Priority: | Major - P3 |
| Reporter: | Shane Harvey | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 1 |
| Labels: | driver-planning-backlog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Driver Changes: | Needed | ||||||||||||||||||||
| Description |
|
Problem: Proposed solution: This change would not have any effect on explicit sessions created with startSession. |
| Comments |
| Comment by Shane Harvey [ 09/Mar/22 ] |
|
Yes this is a duplicate of |
| Comment by Jeremy Mikola [ 09/Mar/22 ] |
|
Is this ticket a duplicate of |
| Comment by Matt Broadstone [ 10/Apr/20 ] |
|
One way I've been able to work around this in the Node.js driver is to make a ClientSession lazily bind to a ServerSession, but the sessions specification explicitly states:
We're still technically complying with this requirement because the session is acquired as soon as it is inspected (either by a user to save off the lsid, or the driver when it needs to apply the session to an operation), but I think it's a bit of a grey area. We might consider loosening this requirement in the sessions spec as part of this work, or at least introduce rationale for why early binding is required and necessary. |
| Comment by Shane Harvey [ 09/Apr/20 ] |
|
I still agree with the proposed solution but I want to point out that this statement is not true in all cases:
The issue is that an implicit server session remains checked out even after the connection is checked in. (The session's lifetime needs to outlive the connection in order to support retryable writes.) So there is a race where more than maxPoolSize implicit server sessions can be created. However, this race is much more rare because checking in a connection should be very fast and would cause very few (if any) extra sessions. |
| Comment by Shane Harvey [ 03/Oct/19 ] |
|
Note I think an implementation of this could be quite simple with only the following changes: |