Server session represents a group of sequential operations performed by a single client against a standalone mongod, replica set, or sharded cluster. When a client connects to the cluster, it will request a new globally unique session id from mongos or mongod. The client may continue to use this session id across different connections to different mongos (in a sharded cluster scenario).
Client session is described more thoroughly in the driver session spec, implemented by drivers in the client side to allow for causal consistency, transactions, and snapshot reads. Perhaps Pymongo’s client_session documentation is a good read in terms of explaining client sessions.
The sentence “cursors may or may not be opened within a session” refers to these client (driver) sessions. For example in Pymongo, you can execute client.start_session() to open a client session and execute collection-level operations such as bulk_write, find, insert_one, etc. all with optional session parameter to tie the operation to a specific client session (e.g. in a transaction). You can also not use the session parameter, and the command will not be tied to a specific session (i.e. executed outside of a currently running transaction).
In short, server sessions and client sessions are tools to allow for advanced capabilities such as transactions or causal consistency. In practice you’ll only need to use client sessions for this.
Thx for the answer. But regarding this, i read the manual somewhere and this doc both say if clients are not explicitly starting a client session, a client session will be implicitly created for it. I also took a look at java driver source code, and this statement seems to be true (though the creation is in a if-else branch).
So does that mean all operations are actually always associated with a client session, and only difference is explicit or implicit?
Yes I think the ultimate goal is to have everything in a session. In the Explicit vs implicit sessions heading in the above driver spec page:
The motivation for starting an implicit session for all methods that don’t take an explicit session parameter is to make sure that all commands that are sent to the server are tagged with a session ID. This improves the ability of an operations team to monitor (and kill if necessary) long running operations. Tagging an operation with a session ID is specially useful if a deployment wide operation needs to be killed.
Basically always using a session in the client side and associating it with a session on the server side allows better manageability as well. Hope this clears it up.