[CSHARP-2876] Expose the API for creation of implicit client sessions Created: 15/Dec/19 Updated: 27/Oct/23 Resolved: 14/Jan/20 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | API |
| Affects Version/s: | 2.10.0 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Roman Kuzmin | Assignee: | Robert Stam |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Description |
|
As far as this question at mongodb-user – https://groups.google.com/forum/#!topic/mongodb-user/c7Do8xYftpg has no answer, and to my knowledge, C# driver keeps creation of implicit sessions to itself (and uses them effectively). In my scenarios it would be useful, clean and less error prone to create such sessions in order to avoid numerous code forks on calling driver methods. Namely, I would like to always have a session, either provided by a higher level caller or implicit created when the caller provides none. In this case, I can always call the driver methods with the session parameter instead of checking the session for null and calling two methods (one depending on the check result). As far as I can see in the sources, the driver methods without parameters create implicit sessions and call their twin methods with this parameter. In a way, I would like to be able to do this as well, "officially". Use of MongoClient.StartSession() was my first attempt but it turned out to be only half working. Per this bug report – https://github.com/nightroman/Mdbc/issues/33 not all servers support this way. Thus, for the moment I decided to call the internal driver method using reflection. It's a hack indeed but it keeps my code clean and simple. I hope, one way or another, the driver exposes the API for implicit sessions and the hack goes. |
| Comments |
| Comment by Roman Kuzmin [ 15/Jan/20 ] |
|
Should I open another issue with suggestion to allow null session parameters, what do you think? Does it look reasonable or hopeless?
I think sooner or later, when people start to use transactions often enough, the current design will show its inconvenience and the issues will be opened anyway. Now, any function with a session parameter has to call every driver function using this inconvenient and error prone pattern `if (session == null) { result = collection.Do(x, y, z); } else { result = collection.Do(session, x, y, z); }`.
|
| Comment by Roman Kuzmin [ 14/Jan/20 ] |
|
Let me put it this way. Your suggestion: > It would probably be better to call the overloads without a session parameter when you don't have a session... But what is "don't have a session"? It is null versus not null. The driver does not provide any other alternative for this. At the same time it does not allow the session parameter to be null. This leads to some inconveniences in using the API. |
| Comment by Roman Kuzmin [ 14/Jan/20 ] |
|
Thank you, I understand. Can you consider alternatives?
Or, for another example, expose another really dummy session type if the approach with null parameter is against some guidelines, style, preferences.
|
| Comment by Robert Stam [ 14/Jan/20 ] |
|
I understand where you're coming from but I'm concerned about making `StartImplicitSession` public. Implicit sessions are intended for internal use only. If we were to let implicit sessions leak out of the driver by making `StartImplicitSession` public we would have to worry about applications unintentionally using implicit sessions in ways that are not allowed (like calling `StartTransaction` on an implicit session etc...). It would probably be better to call the overloads without a session parameter when you don't have a session, though I understand that's a bit tedious. But it should perform slightly better than calling `StartImplicitSession` using reflection and doesn't rely on internal implementation details like implicit sessions. |