[SERVER-32064] A logical session id should be included in all command requests from the mongo shell Created: 21/Nov/17 Updated: 30/Oct/23 Resolved: 25/Jun/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Shell |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.9, 4.0.1, 4.1.1 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Max Hirschhorn | Assignee: | Jack Mulrow |
| Resolution: | Fixed | Votes: | 3 |
| Labels: | ShardingTechDebt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Platforms 2018-01-01, Platforms 2018-01-15, Sharding 2018-06-04, Sharding 2018-06-18, Sharding 2018-07-02 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
| Comments |
| Comment by Daniel Smedegaard Buus [X] [ 10/Oct/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi guys I'm here via this ticket. I've been reading this ticket and the driver sessions specification linked to in it, and I don't see how I can apply this info to overcome my issues in a shell (script) when trying to operate on a sibling db that I authenticated against. In the specification, it instructs on starting sessions and passing along their ids to commands, but the syntax exemplified there is one fitting db.runCommand(). I can't figure out how I would go about doing say, myOtherDb.users.findOne() and passing along the session id? Maybe it's just that this behaviour is unsupported going forward? Thanks | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 28/Sep/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: (cherry picked from commit 8817328f87564a29e9be2ed1a746cf40e89587eb)
(cherry picked from commit 8c5002b06fd737f75941a73785ce75e3ca7f5ce1) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 28/Sep/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: (cherry picked from commit ac59bbf1d0f7c8bfbe949de8f900ffe8b835d9cb) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 19/Jul/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'username': 'jsmulrow', 'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com'}Message: (cherry picked from commit 8c5002b06fd737f75941a73785ce75e3ca7f5ce1) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 19/Jul/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'username': 'jsmulrow', 'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com'}Message: (cherry picked from commit 8817328f87564a29e9be2ed1a746cf40e89587eb) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 19/Jul/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: (cherry picked from commit ac59bbf1d0f7c8bfbe949de8f900ffe8b835d9cb) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 25/Jun/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'username': 'jsmulrow', 'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com'}Message: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 13/Jun/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'username': 'jsmulrow', 'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com'}Message: Revert " This reverts commit 3225e5f0784b8306c700a6280bbb986634129291. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 13/Jun/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'username': 'jsmulrow', 'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com'}Message: Revert " This reverts commit c31687bfcdf25fd9f3a6eb9a2fb07de394de873f. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 13/Jun/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'username': 'jsmulrow', 'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com'}Message: (cherry picked from commit 8817328f87564a29e9be2ed1a746cf40e89587eb) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 13/Jun/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'username': 'jsmulrow', 'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com'}Message: (cherry picked from commit ac59bbf1d0f7c8bfbe949de8f900ffe8b835d9cb) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 13/Jun/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'username': 'jsmulrow', 'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com'}Message: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 13/Jun/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'username': 'jsmulrow', 'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com'}Message: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 30/Mar/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This might have caught, for example, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by A. Jesse Jiryu Davis [ 02/Mar/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yeah, don't do option 2. =) Don't generate a new lsid for each operation. The spec distinguishes between ClientSessions (user-visible API objects) and ServerSessions (logical session ids or "lsids"). When the spec says that implicit sessions are "ended immediately after" the operation it doesn't mean that the actual lsid is tossed, just that the ClientSession is ended. The lsid is returned to the pool. In drivers, when we need an lsid for an implicit session, we pull it from a pool, use it until the operation is complete, then we return it to the pool. This minimizes the number of distinct lsids we use. If you execute a command with an implicit session, its lsid is returned to the pool as soon as the command completes. If you execute "find", "aggregate", etc., then the cursor you create owns the implicit session, and returns it to the pool as soon as it receives the final batch. The session pool is specified here, the summary is: the lsid pool is LIFO, and lsids that haven't been used in over 29 minutes are tossed, instead of used, to avoid running into the server's 30-minute idle timeout. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kevin Pulo [ 02/Mar/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
In the meantime, users looking for this functionality can workaround this by adding the following to their .mongorc.js file:
Or use the code at https://github.com/devkev/mongorcd/blob/master/.mongorc.d/91-default-logical-session.js (UNSUPPORTED). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kevin Pulo [ 02/Mar/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Won't option 2 cause a profusion of logical sessions on the server? Surely creating an implicit logical session for each operation must be against the spec? Either way, my vote is for option 1, since it feels like it better supports the use case of DBAs doing adhoc operations, which may then need to be cluster-wide killed if they go awry. I would say that the interactive shell should also print out the session id at startup, so that DBAs are aware of it. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kaloian Manassiev [ 15/Feb/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
So just to be clear - this ticket is a request to make the driver in the shell in line with the driver specification, right? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by A. Jesse Jiryu Davis [ 07/Feb/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
max.hirschhorn asked me to clarify how drivers handle sessions and causal consistency.
If the user doesn't pass a ClientSession to an operation, then the driver passes an implicit "lsid" to the server, but that operation is not ever causally consistent. IOW, drivers use lsid two ways:
So the specs imply (without explaining very clearly) that "explicit" sessions are causal by default, and "implicit" sessions are never causal. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Gregory McKeon (Inactive) [ 05/Feb/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Sending to sharding as we believe they own logical sessions. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Max Hirschhorn [ 21/Nov/17 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
It would be fairly time-consuming to go through all of the methods on DB and DBCollection to implicitly create a logical session id if DB.prototype.getSession() returns a _DummyDriverSession instance. I have two proposals of how we could address this: Option 1Use a single session to any user operations run through a DB instance that wasn't created via a call to Mongo.prototype.startSession(). This doesn't satisfy the "and ended immediately after this operation completes" part of the specification.
Option 2Generate a new UUID for every command request.
|