[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:
Duplicate
duplicates DRIVERS-1030 Drivers should check out an implicit ... Closed
Related
is related to NODE-2216 Logical Sessions grow continuously wh... Closed
is related to DRIVERS-1030 Drivers should check out an implicit ... Closed
Driver Changes: Needed

 Description   

Problem:
When the number of concurrent application requests are larger than the number of available connections, the driver may generate many more implicit sessions than connections. For example with maxPoolSize=1 and 100 threads, 100 implicit sessions may be created. This increases the load on the server since session state is cached in memory. In the worst case this kind of workload can hit the session limit and trigger TooManyLogicalSessions.

Proposed solution:
Drivers should check out an implicit session only after checking out a connection. This change will limit the number of implicit sessions to no greater than an application's maxPoolSize (ignoring operations that hold on to the session like cursors).

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 DRIVERS-1030.

Comment by Jeremy Mikola [ 09/Mar/22 ]

Is this ticket a duplicate of DRIVERS-1030? That issue is currently being implemented while this is in the backlog, and both appear to have the same description.

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:

A ``ClientSession`` MUST be associated with a ``ServerSession`` at the time ``startSession`` is called.

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:

This change will limit the number of implicit sessions to no greater than an application's maxPoolSize (ignoring operations that hold on to the session like cursors).

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:
1) Do not assign a ServerSession when creating an implicit ClientSession.
2) Assign a ServerSession to the implicit ClientSession (if one is not already assigned) after checking out the connection.

Generated at Thu Feb 08 08:24:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.