[DRIVERS-2165] Consider allowing (async) drivers to use locks to prevent concurrent ClientSession usage Created: 21/Nov/19  Updated: 01/Sep/22  Resolved: 01/Sep/22

Status: Closed
Project: Drivers
Component/s: Sessions
Fix Version/s: None

Type: Spec Change Priority: Major - P3
Reporter: Kaitlin Mahar Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Related
related to DRIVERS-2096 Document usability of async methods w... Backlog
Driver Changes: Needed

 Description   

In an asynchronous driver, it is easy for users to accidentally use a ClientSession concurrently for multiple operations. (see SERVER-43889 for an example of a user doing this in the C# driver.)

Without some kind of locking mechanism built into ClientSession, the best we can do is thoroughly document that sessions can only be used by one operation at once and that users need to await the result of one operation before firing off another.

Right now, the spec explicitly says:

Drivers MUST NOT attempt to detect simultaneous use by multiple threads or processes 

(rationale here). We should consider amending the spec to allow drivers to make their ClientSession types thread-safe.



 Comments   
Comment by Shane Harvey [ 01/Sep/22 ]

Closing as a duplicate of DRIVERS-1012.

Comment by Shane Harvey [ 13/Jan/20 ]

The full rationale in the spec:

[Drivers MUST NOT attempt to detect unsafe multi-threaded or multi-process use of ClientSession] because doing so would provide an illusion of safety. It doesn't make these instances thread safe. And even if when testing an application no such exceptions are encountered, that doesn't prove anything. The application might still be using the instances in a thread-unsafe way and just didn't happen to do so during a test run. The final argument is that checking this would require overhead that doesn't provide any clear benefit.

I think one clear benefit of detecting concurrent ClientSession usage, especially for async APIs, is that we can raise an informative error to the user that something is wrong. The buggy example in SERVER-43889 is easy to write. Moreover, the server may not always return an error in this case and even when it does the error is not easy for a user to diagnose (eg "Cannot start transaction 1 on session <> because a newer transaction 3 has already started").

However, one thing I don't think we should do is serialize access to the ClientSession because that would only provide the illusion that ClientSession is thread-safe. Better to raise an error to the user so that they can refactor the code with this session limitation in mind.

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