[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: |
|
||||||||||||
| Driver Changes: | Needed | ||||||||||||
| Description |
|
In an asynchronous driver, it is easy for users to accidentally use a ClientSession concurrently for multiple operations. (see 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:
(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:
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 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. |